SEP-2149：MCP 小组治理与章程模板

社区译文；来源： MCP 29affa6b

摘要

本 SEP 为 MCP 的两类协作小组建立治理规则和标准化章程模板：**Working Group（WG，工作组）**与 Interest Group（IG，兴趣组）。Working Group 产出具体交付物，包括 SEP、实现和代码。Interest Group 通过讨论和知识共享来识别问题并收集需求。治理规则定义所有小组都必须遵守的要求，并在适当之处对 IG 采用较宽松的要求。章程模板定义每个小组记录自身具体使命、范围、领导和工作的结构。二者共同回应了社区关于授权不清晰以及不同小组流程不一致的反馈。

本 SEP 与 SEP-2148：MCP 贡献者阶梯配套；后者定义本文通篇引用的组织级贡献者角色（Member、Maintainer、Core Maintainer、Lead Maintainer）。小组领导角色与贡献者阶梯相交：WG Lead 和 IG Facilitator 必须至少在阶梯上具有 Member 身份，参与小组也是获得阶梯晋升认可的一条路径。

动机

社区访谈和反馈发现当前小组结构存在若干挑战：

1. 权限不清晰：工作组可以自主作出哪些决定、哪些决定需要 Core Maintainer 批准，并不总是明确。这会导致犹豫和瓶颈。

2. 决策方式不一致：不同小组采用不同惯例。一次会议作出的决定可能在另一次会议中被推翻，却没有明确的解决流程。

3. 参与方式不清晰：社区成员不确定谁应参与小组、有哪些参与程度，以及如何提高参与度。

4. 范围蔓延：缺乏明确边界时，小组可能逐渐扩展到其他小组负责或自身职责之外的领域。

5. 缺少升级路径：小组陷入僵局时，没有明确的解决路径，导致分歧长期持续或计划被放弃。

6. WG/IG 区别：参与者并不总能清楚理解 Working Group 与 Interest Group 的区别，因而对产出和投入产生不匹配的预期。

标准化章程模板和共享治理规则可以解决这些问题：它们为所有小组建立一致流程，同时要求每个小组明确界定自身的具体范围和边界。

规范

MCP 设有两类协作小组：

• **Working Group（WG，工作组）**产出具体交付物，包括 SEP、参考实现和代码。成员应积极贡献。
• **Interest Group（IG，兴趣组）**围绕某个主题领域促进讨论和知识共享。其产出包括问题陈述、用例和建议。成员应积极贡献。

本规范分为两部分：

1. 小组治理：适用于所有 MCP 小组（WG 和 IG）的规则，并在适用之处注明差异
2. 章程模板：每个小组用于定义自身具体使命、范围和运作方式的结构

第一部分：小组治理

以下规则适用于所有 MCP Working Group 和 Interest Group。各小组的章程不得推翻这些要求。WG 与 IG 适用不同规则时，本文会明确注明。

1.1 领导

每个小组设一名或多名 Lead（Interest Group 中称为 Facilitator）。

所有 Lead 和 Facilitator 的要求：

• 至少具有 MCP 贡献者阶梯中的 Member 身份
• 已在小组范围领域展现持续投入
• 能够促进跨组织协作
• 承诺负责小组运作
• 小组及其领导至少由两名 Core Maintainer 或一名 Lead Maintainer 赞助

WG Lead 的额外要求：

• 承诺每周为 WG 活动投入 2-3 小时

1.2 领导职责

所有 Lead 均负责：

• 安排并主持定期会议
• 与参与者共同制定议程，并提前发布
• 确保会议记录在 48 小时内发布
• 维护小组文档
• 在 https://github.com/modelcontextprotocol/access 中维护成员列表和对应的访问权限列表
• 主动招募并留住来自不同组织、代表不同观点的广泛成员

WG Lead 还负责：

• 推动提案完成 SEP（Specification Enhancement Proposal，规范增强提案）流程并得到解决
• 分诊 WG 范围内的 SEP，包括关闭不符合路线图的 SEP（必须记录理由；作者可以向 Core Maintainer 申诉）
• 将受阻的决定连同清晰上下文升级给 Core Maintainer
• 维护工作组路线图
• 持续就小组的总体方向征求一名或多名 Core Maintainer 的反馈
• 每季度向社区和 Core Maintainer Group 提供状态更新

1.3 参与层级

所有小组均采用以下参与层级。请注意，WG Member 是特定小组内的参与层级，不同于贡献者阶梯定义的组织级 Member 角色。个人可以是某个特定小组的 WG Member，却不具有组织级 Member 身份，反之亦然。

Interest Group 主要采用 Observer、Participant 和 Facilitator 层级。如果工作需要正式决策，IG 可以采用 WG Member 层级，但并非必须采用。

成为 WG Member（适用于 WG 以及采用 WG Member 层级的 IG）：

• 持续参与超过 3 个月
• 作出有意义的贡献（代码、规范文本、评审或文档）
• 由现有 WG Member 或 Lead 提名
• Lead、Core Maintainer 或 Lead Maintainer 在 7 天内没有提出异议

WG Member 职责：

• 继续本着诚信原则作出贡献
• 在相应小组的成员列表中维护姓名、所属组织和 Discord 名称

**活跃与 Emeritus：**连续 3 个月未参与的 WG Member 将转为 emeritus（荣誉）状态，并可通过证明重新参与而恢复活跃状态。

1.4 决策流程

本节主要适用于作出约束性决定（就技术设计、规范变更等达成共识）的 Working Group。Interest Group 通常通过讨论中的粗略共识运作，不作出约束性决定；其产出是建议、问题陈述和用例。采用 WG Member 层级的 IG 可以对内部决定使用本流程。

WG 共识通过以下渐进流程达成。进入下一步之前，必须先尝试当前步骤：

步骤 1：Lazy Consensus（默认）

• 公布提案并明确截止时间（次要事项至少 5 天，重大事项至少 10 天）
• 沉默即表示同意
• 任何 WG Member 均可提出有记录的异议以阻止提案
• 阻止提案时必须提出替代方案或明确的解决标准
• 截止时间前无人阻止，提案即获接受

步骤 2：正式投票（Lazy Consensus 受阻时）

以下情况会触发正式投票：

• WG Member 在 Lazy Consensus 期间阻止提案
• 一名 Lead 或至少三名 WG Member 要求正式投票

投票规则：

• 法定人数：活跃 WG Member 的 50%
• 通过门槛：例行事项需简单多数；范围变更需 2/3 多数
• Core Maintainer 的反馈属于建议，除非明确声明具有约束力
• 所有投票均须记录理由

步骤 3：升级（投票未能解决时）

如果投票未能解决事项（未达到法定人数、未通过或结果受到争议），Lead 将按照下文定义的升级路径把事项升级给 Core Maintainer。

1.5 升级路径

对于小组范围内的技术和设计分歧，小组应先在内部解决，再请 Core Maintainer 介入。对于 WG，这意味着使用上述决策渐进流程（Lazy Consensus → 投票 → 升级）。对于 IG，Facilitator 应在升级前尝试达成粗略共识。

有些分歧不适合在小组层面解决，应直接升级给 Core Maintainer：

• 范围争议（某个主题是否属于小组章程范围）
• 权限争议（小组是否有权决定某个事项）
• 跨组冲突（涉及多个 WG 或 IG 的分歧）
• 行为准则或行为方面的问题
• 成员身份或参与争议

需要升级时：

1. Lead 记录相关决定、已考虑的选项和分歧点
2. Lead 向 Core Maintainer Group 提交升级事项，并明确请求解决的问题
3. Core Maintainer Group 指定一名与争议各方没有共同组织隶属关系的 Core Maintainer 来解决问题，并向小组反馈
4. 被指定的 Core Maintainer 可以：(a) 提供具有约束力的指导；(b) 要求补充信息；或 (c) 建议由完整的 Core Maintainer Group 审议
5. 时间线：升级事项应在 5 个工作日内得到首次响应

1.6 会议要求

Lead 根据小组当前需求和生命周期阶段决定会议频率、形式和时长。会议没有固定的频率要求：临近规范发布的 WG 可以每周开会，处于早期探索阶段的 IG 可以每月开会，也可以主要采用异步工作方式。

无论会议采用何种形式或频率，所有小组会议均必须：

• 向所有社区参与者开放（不得举行闭门会议或组织内部会议）
• 至少提前 7 天发布到 meet.modelcontextprotocol.io
• 发布议程并允许公众访问。议程或议程链接应作为 Meeting Notes 类别中的 GitHub Discussion发布
• 在 48 小时内将会议记录发布到同一个 Discussion

Lead 应积极邀请 WG Member 和 Participant 承担准备议程、记录会议和主持讨论等运营职责。

1.7 沟通渠道

所有小组均使用以下渠道：

除 Discord 外，小组还可以在 GitHub Discussions中建立讨论类别。Lead 将获得管理和主持讨论所需的适当角色。

1.8 报告

Working Group 每季度提供更新（1 月、4 月、7 月和 10 月底），包括：

• 交付物进展
• 受阻事项和升级事项
• 成员变动
• 后续优先事项
• 资源需求

季度更新以文档形式发布到 Working Group 的 GitHub Discussions类别中。也可以选择在 Core Maintainer 会议上与 Core Maintainer 讨论这些更新。

Interest Group 没有正式报告要求，但应保持章程和成员列表为最新状态。

1.9 生命周期

Working Group 的成立：

• 必须存在一个得到广泛认可、需要协调的问题
• 提交 PR，在 docs/community/<name>/overview.mdx 中创建 WG；该 PR 受 CODEOWNERS 约束，需要 Maintainer 批准
• 提交 PR，在 docs/community/<name>/charter.mdx 中添加章程；该 PR 受 CODEOWNERS 约束，需要一名 Core Maintainer 批准（该 Core Maintainer 应通知所有 Core Maintainer）
• 初始成员列表由 WG Lead 批准

Interest Group 的成立：

• 在 Discord 的 #wg-ig-group-creation 频道填写创建模板
• 由一名 Core Maintainer 评审提案；IG 及其 Facilitator 必须至少由两名 Core Maintainer 或一名 Lead Maintainer 赞助
• 获得赞助后，由 Facilitator 组织 IG 并创建章程

退休：

• WG：由 WG Lead 或 Core Maintainer 提出退休并说明理由；需要 Core Maintainer 或 Lead Maintainer 批准。WG 在持续一段时间没有活跃工作，或已完成所有计划交付物时，也会退休。
• IG：Core Maintainer 或 Lead Maintainer 可以让不再活跃或不再需要的 IG 退休。
• 两种情况下，文档均会归档，频道会标记为非活跃。

1.10 章程修订

修改小组章程（WG 或 IG）需要：

• 由 Lead/Facilitator 或 Core Maintainer 提议
• 由 Core Maintainer 批准

第二部分：章程模板

每个 MCP Working Group 和 Interest Group 都必须按照此模板结构维护章程文档。章程以 MDX 文件形式存储在 modelcontextprotocol 仓库的 docs/community/<group-name>/charter.mdx，并添加到 docs/docs.json 文件中。本模板的可复制版本发布在 docs/community/charter-template.mdx。

章程记录每个小组的具体信息。第一部分的治理规则自动适用，无需在章程中重复。标有 （仅限 WG） 的章节对 Working Group 是必需的，对 Interest Group 则是可选的。

1. 小组类型

说明该小组是 Working Group 还是 Interest Group。

2. 使命陈述

用 2-3 句话概述小组宗旨，并说明：

• 要解决的问题领域
• 为何需要跨领域协作
• 对于 WG：小组将产出哪些具体交付物
• 对于 IG：小组将促进哪些讨论和知识共享

WG 示例：

Transport Working Group 旨在演进 MCP 的传输机制，以支持从本地子进程通信到水平扩展云部署等多样化部署场景，同时保持协议一致性和向后兼容性。

IG 示例：

Enterprise IG 探索在企业环境中部署 MCP 所面临的挑战，收集用例和需求，为未来的规范工作提供依据。

3. 范围

范围内：逐项列出职责。

对于 WG，包括：

• 规范工作：负责的具体规范章节或 SEP
• 参考实现：SDK 组件或参考实现
• 跨领域事项：需要与其他小组协调的领域
• 文档：文档职责

对于 IG，包括：

• 讨论的主题领域
• 产出类型（问题陈述、用例、建议）

范围外：明确说明哪些事项不在小组职责范围内，以防止使命蔓延。

相关小组：列出工作有交集的其他 WG 或 IG，以及重叠工作的性质。

4. 领导

Lead/Facilitator 表格应包含：

• 角色、姓名、组织、GitHub 用户名、任期

领导要求和职责由治理规则（第 1.1 节和第 1.2 节）定义。

5. 权限与决策权（仅限 WG）

每个 WG 都必须明确界定自身决策权限。决策流程和升级路径由治理规则（第 1.4 节和第 1.5 节）定义。本节记录 WG 可以在哪个权限层级作出哪些决定。

示例：

IG 不作出约束性决定，因此不需要本节。

6. 成员

列出当前小组成员及其参与层级（如有）。如果尚无成员，则省略本节内容。 参与层级和成员资格标准由治理规则（第 1.3 节）定义。

7. 运作方式

记录小组当前的会议方式。会议要求和沟通渠道由治理规则（第 1.6 节和第 1.7 节）定义。

示例：

8. 交付物与成功指标（仅限 WG）

进行中的工作项：

**成功标准：**衡量 WG 成功的可量化结果。

季度报告要求由治理规则（第 1.8 节）定义。

IG 不跟踪正式交付物，但可以在章程中列出当前讨论主题或计划产出（问题陈述、建议等）。

9. 变更日志

按日期和变更内容记录章程版本。

理由

为什么将治理规则与章程模板分开？

将固定治理规则与各小组的章程模板分开，可以明确区分所有小组统一遵守的内容（决策方式、成员层级、升级）与各小组自行定义的内容（范围、领导名单、交付物）。这可以防止小组流程意外分化，同时在需要的地方保留灵活性。

为什么同时涵盖 WG 和 IG？

Working Group 和 Interest Group 用途不同，但有共同的运营需求，包括领导、会议要求、沟通渠道和升级路径。统一的治理框架既能确保一致性，也能明确说明 IG 适用较宽松要求的方面（没有正式决策权、不跟踪交付物、没有季度报告）。

为什么使用标准化模板？

标准化可以：

• 确保所有小组处理关键治理问题
• 让社区成员更容易理解任何小组的运作方式
• 降低成立新小组的开销
• 通过明确记录建立问责机制

为什么明确列出权限表？

权限表直接回应了“权限不清晰”的反馈。通过列举决定类型和所需批准，WG 和社区成员可以准确了解哪些事项可以自主决定，哪些事项需要升级。IG 产出建议而非约束性决定，因此不受此要求约束。

为什么设置分层参与方式？

不同参与层级满足社区的不同需求：

• Observer 可以在不作承诺的情况下学习
• Participant 可以参与贡献，而不承担 WG Member 的全部职责
• WG Member 承担责任并获得决策权（主要适用于 WG）
• Lead/Facilitator 提供运营连续性

为什么默认采用 Lazy Consensus？

Lazy Consensus 可以：

• 提高例行事项的决策效率
• 减少会议负担
• 通过公告和截止时间结构记录决定
• 为实质性关切保留阻止权

投票仅用于有争议或影响较大的决定。

模型来源

本模板改编自 Kubernetes 治理结构，并根据社区访谈发现的 MCP 具体需求进行了调整。

向后兼容性

现有小组的过渡安排

本 SEP 获准时已存在的 Working Group 和 Interest Group 将按原有资格继续存在：它们被视为有效小组，无需按照第 1.9 节定义的成立流程重新申请。

但是，现有小组必须在本 SEP 获准后的 8 周内创建符合第二部分模板的章程。过渡期间：

• 现有小组继续按当前流程运作
• Lead/Facilitator 负责起草章程
• Core Maintainer 将评审并批准 WG 和 IG 的章程
• 未在 8 周内制定章程的小组将被视为非活跃，并可能进入退休流程

安全影响

没有直接的安全影响。不过，明确的授权和决策流程通过确保决定在适当层级作出并承担相应责任，间接支持安全。

参考实现

本 SEP 通过以下内容实现：

1. docs/community/working-interest-groups.mdx：将治理规则（第一部分）作为 Working and Interest Groups 页面发布在 modelcontextprotocol.io
2. docs/community/charter-template.mdx：可复制的章程模板（第二部分），由上述页面链接
3. 将两个页面添加到 docs/docs.json 的 Community → Governance 导航组中
4. 现有 WG 和 IG 必须在获准后的 8 周内，在 docs/community/<name>/charter.mdx 创建符合要求的章程