治理

ACP 项目的治理方式

以下是一个过渡性治理模型，旨在为 ACP 上协作的各方提供更清晰的角色和职责。

ACP 由 Zed 和 JetBrains 共同治理，双方协作确保协议服务于更广泛的生态系统。我们旨在透明运营，并以 ACP 及其社区的最佳利益做出决策，同时致力于向独立基金会过渡。

本文档描述了 Agent Client Protocol (ACP) 的治理模型。它定义了指导项目运营和决策的角色、职责和流程。

原则

我们旨在透明运营，并以 ACP 及其社区的最佳利益做出决策。

技术治理

ACP 项目采用层级结构，类似于 MCP、Rust Foundation 项目和其他开源项目：

  • 一个由贡献者组成的社区，他们提交 issue、发起 pull request 并为项目做贡献。
  • 一小部分维护者负责推动 ACP 项目内的组件，如 SDK、文档等。
  • 贡献者和维护者由核心维护者监督，核心维护者负责推动整体项目方向。
  • 核心维护者中有两位首席核心维护者，他们是兜底的决策者。
  • 维护者、核心维护者和首席核心维护者组成 ACP 指导小组。

所有维护者都应 strongly 倾向于 ACP 的设计理念。

渠道

技术治理通过所有维护者、核心维护者和首席维护者的共享沟通渠道来促进。每个维护者小组可以选择额外的沟通渠道，但所有决策及其支持性讨论都必须记录并在其中一个主要沟通渠道中公开提供。

贡献者

任何提交代码、文档或其他改进的人都被视为贡献者。贡献者没有正式的决策权，但被鼓励参与关于项目方向的讨论并提出变更建议。

维护者

维护者负责 ACP 项目内的工作组和兴趣组。这些通常是独立的仓库，如特定语言的 SDK，但也可能扩展到仓库的子目录，如 ACP 文档。维护者可以采用自己的规则和程序来做决策。维护者应独立地为其各自的项目做出决策，但可以在需要时将问题上报或移交给核心维护者。维护者负责：

  • 与社区贡献者进行深思熟虑且富有成效的互动，
  • 维护和改进其负责的 ACP 项目领域，
  • 支持文档、路线图和 ACP 项目的其他相关部分，
  • 向核心维护者展示来自社区的想法。

新的维护者由现任核心维护者通过共识或多数投票产生，基于其对项目持续且高质量的贡献、与项目目标的一致性以及对社区标准的承诺。准维护者应在参与讨论、issue 分拣和代码或文档改进方面有良好的记录。维护者拥有对其各自仓库的写入和/或管理权限。维护者可随时通知其他维护者后卸任。在极少数情况下，如果维护者长期不活跃、违反行为准则或行为违背项目利益，可由其他维护者通过共识或三分之二绝对多数投票罢免。维护者可由核心维护者或首席核心维护者随时罢免且无需理由。

核心维护者

核心维护者是拥有 ACP 源代码写入权限的贡献者。他们审查和合并贡献，参与项目决策，并帮助引导和指导新贡献者。核心维护者应深入理解 Agent Client Protocol 及其规范。他们的职责包括：

  • 设计、审查和引导 ACP 规范以及 ACP 项目所有其他部分（如文档）的演进，
  • 阐明项目的凝聚性长期愿景，
  • 以公平和透明的方式调解和解决有争议的问题，在可能时寻求共识，在必要时做出果断决策，
  • 任命或罢免维护者，
  • 以 ACP 的最佳利益管理 ACP 项目。

核心维护者作为一个群体，有权通过多数投票否决维护者做出的任何决策。核心维护者有权自行决定解决争议。核心维护者应公开阐明其决策过程。核心小组负责制定自己的决策程序。新的核心维护者由现任核心和首席维护者通过共识或多数投票产生，基于其对项目持续且高质量的贡献、与项目目标的一致性以及对社区标准的承诺。准维护者应在参与讨论、issue 分拣和代码或文档改进方面有良好的记录。核心维护者通常拥有所有 ACP 仓库的写入和管理权限，但应使用与外部贡献者相同的贡献机制（通常是 pull request）。可基于安全考虑做出例外处理。核心维护者可随时通知其他核心维护者后卸任。在极少数情况下，如果核心维护者长期不活跃、违反行为准则或行为违背项目利益，可由其他核心维护者通过共识或三分之二绝对多数投票罢免。

首席维护者（BDFL）

ACP 有两位首席维护者：Ben Brandt（Zed Industries）和 Sergey Ignatov（JetBrains）。首席维护者可以否决核心维护者或维护者的任何决策。这种模式在开源社区中也通常被称为终身仁慈独裁者（BDFL）。首席维护者应公开阐明其决策过程并给出明确的决策理由。首席维护者是核心维护者小组的成员。首席维护者在可能的情况下是 ACP 项目所有基础设施的管理员。这包括但不限于所有沟通渠道、GitHub 组织和仓库。首席维护者是主要联系人，负责：

  • 在官方事务中代表 ACP。
  • 协调关于项目方向的重大决策。
  • 审批项目支出。

首席维护者可通知其他首席维护者后卸任。他们可以推荐继任者，但选择继任者是留任首席维护者的责任。如果所有首席维护者都卸任，核心维护者将通过共识或多数投票选出新的首席维护者。

决策流程

核心维护者小组每两周举行一次会议，讨论和投票表决提案，以及讨论任何需要的话题。可以使用 ACP RFD 流程 和 Zulip 聊天来讨论和投票较小的提案。

流程

核心和首席维护者负责 Agent Client Protocol 的所有方面，包括文档、issue、内容建议以及 ACP 项目 下的所有其他部分。维护者负责其 ACP 项目领域的文档、issue 和内容建议，但鼓励参与 ACP 项目的一般维护。维护者、核心维护者和首席维护者应使用与外部贡献者相同的贡献流程，而非直接修改仓库。这提供了对意图的洞察和讨论的机会。

工作组和兴趣组

ACP 的协作和贡献围绕两种结构组织：工作组和兴趣组。兴趣组负责识别和阐述 ACP 应解决的问题，主要通过在社区内促进开放讨论来实现。相比之下，工作组专注于通过协作产出交付物（如 RFD 或社区拥有的规范实现）来开发具体的解决方案。虽然兴趣组的输入可以帮助证明工作组的成立合理性，但这不是严格的要求。同样，在提交 RFD 或其他社区提案时，鼓励来自兴趣组或工作组的贡献，但不是强制性的。我们强烈鼓励所有有意参与特定 RFD 工作的贡献者首先在兴趣组内协作。这一协作过程有助于确保所提议的 RFD 符合协议需求，并且对其采用者来说是正确的方向。

治理原则

所有小组在遵守以下核心原则的前提下进行自治：

  1. 清晰的贡献和决策流程
  2. 开放沟通和透明决策

他们必须：

  • 记录其贡献流程
  • 保持透明沟通
  • 公开做出决策（小组必须发布会议记录和提案）

未指定流程的项目和工作组默认使用：

维护责任

没有专门维护者的组件（如文档）由核心维护者负责。这些组件通过 pull request 遵循标准贡献指南，由维护者进行审查，并在重大变更时升级至核心维护者审查。鼓励核心维护者和维护者改进 ACP 项目的任何部分，无论正式的维护分配如何。

沟通

核心维护者会议

核心维护者小组每两周举行一次会议，讨论提案和项目。关于提案的记录应公开。会议本身为邀请制。如果你有议题需要核心维护者讨论并希望加入议程，请提前在 Zulip 中告知核心维护者你想讨论的内容，你将被邀请参加下一次会议。

公开聊天

ACP 项目维护着一个公开的 Zulip 聊天，为不同小组提供开放的聊天频道。ACP 项目可能设有用于特定沟通的私有频道。

提名、确认和罢免维护者

原则

  • 模块维护者小组的成员资格是在个人通过贡献、审查和讨论展示了其工作领域的深厚专业知识，并与整体 ACP 方向保持一致后，基于能力授予的。
  • 对于维护者小组的成员资格，个人必须展示对整体 ACP 原则的强烈且持续的认同。
  • 模块维护者或核心维护者没有任期限制
  • 如果子项目维护者长时间不积极参与，将其维护状态转为”荣誉”状态的宽松标准。每个维护者小组可以定义适合其领域的不活跃期限。

提名和罢免

  • 核心维护者负责添加和罢免维护者。他们将考虑现有维护者的意见。
  • 首席维护者负责添加和罢免核心维护者。

提名流程

如果维护者（或核心/首席维护者）希望提名候选人供核心/首席维护者审议，应遵循以下流程：

  1. 收集提名的证据。这通常以考虑维护者资格的仓库上已合并 PR 的历史记录形式出现。
  2. 在相关小组的维护者中讨论他们是否支持批准该提名。
  3. 私信核心维护者在 Zulip 中创建一个私有频道，格式为 nomination-{name}-{group}。添加所有核心维护者、首席维护者和相关小组的共同维护者。
  4. 为被提名人提供背景信息。请参阅下方关于应包含内容的建议。
  5. 创建一个 Zulip 话题并请核心/首席维护者对该提名投票赞成/反对。鼓励达成共识，但不是必需的。
  6. 在核心/首席维护者讨论和/或投票后，如果提名获得通过，具有更新 GitHub 和 Zulip 权限的相关成员将被提名人添加到相应的组中。提名者应在相关的 Zulip 频道中宣布新的维护者资格。
  7. 临时的 Zulip 频道将在一周后删除。

关于提名某人时与核心维护者分享的信息类型的建议：

  • GitHub 个人资料链接、LinkedIn 个人资料链接、Zulip 用户名
  • 你为哪个/哪些小组提名该个人担任维护者
  • 该/这些小组是否同意此人应晋升为维护者
  • 描述其迄今为止的贡献（包括最重大贡献的链接）
  • 描述预期的未来贡献（例如，他们是否渴望成为维护者？他们是否有能力做到？）
  • 关于该个人的其他背景信息（例如，当前雇主、参与 ACP 的动机）
  • 你认为与提名相关的任何其他信息

当前的维护者

请参阅 维护者列表。

安全策略和漏洞披露

  • Zed 将在 Zed 团队和其他维护者之间对所有潜在的安全和漏洞问题进行分拣
  • 报告可提交至 security@zed.dev

法律、许可和贡献者条款

  • ACP 组织中的所有仓库应使用 Apache 2.0 许可证。
  • 本项目不要求 Contributor License Agreement (CLA)。相反，贡献按以下条款接受：

通过向本项目贡献，你同意你的贡献将按 Apache License, Version 2.0 获得许可。你确认你有合法权利提交你的工作，你没有包含你没有权利的代码，并且你理解贡献不需要 Contributor License Agreement (CLA)。