Documentation Index
Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt
Use this file to discover all available pages before exploring further.
最终版流程
| 字段 | 值 |
|---|
| SEP | 2149 |
| 标题 | MCP 群组治理与章程模板 |
| 状态 | 最终版 |
| 类型 | 流程 |
| 创建日期 | 2025-01-15 |
| 作者 | David Soria Parra (@dsp-ant), Sarah Novotny (@sarahnovotny) |
| 赞助人 | David Soria Parra (@dsp-ant) |
| PR | #2149 |
本 SEP 为 MCP 的两种协作群组类型建立了治理规则和标准化章程模板：工作组 (WGs) 和 兴趣小组 (IGs)。工作组产出具体的交付物——SEP、实现方案和代码。兴趣小组促进讨论和知识共享，以识别问题并收集需求。治理规则定义了所有群组必须遵循的要求，并在适当情况下对 IGs 设定较轻的预期。章程模板定义了每个群组用于记录其具体使命、范围、领导层和工作的结构。它们共同解决了社区关于权限委托不明确和群组间流程不一致的反馈。
本 SEP 是 SEP-2148: MCP 贡献者阶梯 的配套文件，后者定义了本文档中引用的组织级贡献者角色（成员、维护者、核心维护者、首席维护者）。群组领导角色与贡献者阶梯相交：工作组负责人和兴趣小组协调人必须在阶梯上至少持有成员状态，群组参与是被认可的阶梯晋升途径。
社区访谈和反馈指出了当前群组结构的几个挑战：
-
权限不明确：并不总是清楚工作组可以自主做出哪些决定，哪些需要核心维护者批准。这导致犹豫和瓶颈。
-
决策不一致：不同群组以不同的规范运作。一次会议中做出的决定可能在另一次会议中被反驳，没有明确的解决流程。
-
参与困惑：社区成员不确定谁应该参与群组，存在哪些参与级别，以及如何更多地参与。
-
范围蔓延：如果没有明确的界限，群组可能会逐渐扩展到其他群组拥有的领域或其任务范围之外。
-
缺少升级路径：当群组陷入僵局时，没有明确的解决路径，导致分歧长期存在或计划被放弃。
-
工作组/兴趣小组区别：参与者并不总是清楚工作组和兴趣小组之间的区别，导致对产出和承诺的预期不匹配。
标准化的章程模板和共享治理规则通过建立所有群组的一致流程，同时要求每个群组明确定义其具体范围和界限，来解决这些问题。
MCP 维护两种类型的协作群组：
- 工作组 (WGs) 产出具体的交付物——SEP、参考实现方案和代码。预期需要积极贡献。
- 兴趣小组 (IGs) 促进围绕主题领域的讨论和知识共享。它们产出问题陈述、用例和建议。预期需要积极贡献。
本规范分为两部分：
- 群组治理 — 适用于所有 MCP 群组（工作组和兴趣小组）的规则，适用之处注明差异
- 章程模板 — 每个群组填写的结构，用于定义其具体使命、范围和运作
第一部分：群组治理
以下规则适用于所有 MCP 工作组和兴趣小组。个别章程不能覆盖这些要求。在工作组和兴趣小组之间规则不同的地方，会明确注明。
1.1 领导层
每个群组有一个或多个 负责人（兴趣小组称为 协调人）。
所有负责人和协调人的要求：
- 在 MCP 贡献者阶梯 上至少持有成员状态
- demonstrated 与群组范围领域的持续参与
- 能够跨组织边界进行协调
- 承诺运行群组的运作
- 群组及其领导层由至少两名核心维护者或一名首席维护者赞助
工作组负责人的额外要求：
1.2 领导职责
所有负责人负责：
工作组负责人还负责：
- 推动提案通过 SEP（规范增强提案）流程直至解决
- 分类工作组范围内的 SEP，包括关闭不符合路线图的 SEP（需有文档记录的理由；作者可向核心维护者申诉）
- 将受阻的决策升级给核心维护者，并提供清晰的背景
- 维护工作组的路线图
- 持续向一名或多名核心维护者征求关于群组总体方向的反馈
- 向社区和核心维护者群组提供季度状态更新
1.3 参与层级
所有群组使用以下参与层级。注意 工作组成员 是特定于群组的参与层级，不同于 贡献者阶梯 中定义的组织级 成员 角色——个人可以是特定群组的工作组成员而不持有组织级成员状态，反之亦然。
| 层级 | 描述 | 权限 |
|---|
| 观察者 | 任何有兴趣关注群组工作的人 | 读取权限，可参加会议，有限的讨论参与 |
| 参与者 | 群组讨论的积极贡献者 | 可提议议程项目，参与异步投票 |
| 工作组成员 | 具有公认专业知识的持续贡献者 | 计入法定人数（仅限工作组） |
| 负责人/协调人 | 群组的运营领导 | 设置议程、主持、升级 |
- 持续参与超过 3 个月
- 有意义的贡献（代码、规范文本、审查或文档）
- 由现有工作组成员或负责人提名
- 7 天内负责人、核心维护者或首席维护者无异议
工作组成员职责：
- 继续善意贡献
- 在相应群组的成员列表中维护姓名、组织和 Discord 名称
活跃与名誉： 连续 3 个月不参与的工作组成员将转为名誉状态，并可通过展示重新参与而回归。
1.4 决策流程
本节主要适用于工作组，工作组做出具有约束力的决策（技术设计共识、规范变更等）。兴趣小组通常在讨论中通过粗略共识运作，不做具有约束力的决策——它们的产出是建议、问题陈述和用例。采用工作组成员层级的兴趣小组可以使用此流程进行内部决策。
工作组共识 通过以下 progression 达成。在进入下一步之前尝试每一步：
步骤 1：懒惰共识（默认）
- 提案宣布时带有明确的截止日期（次要项目最少 5 天，重要项目 10 天）
- 沉默即同意
- 任何工作组成员都可以凭借文档记录的异议进行阻止
- 阻止必须提出替代方案或明确的解决标准
- 如果在截止日期前没有提出阻止，提案即被接受
步骤 2：正式投票（当懒惰共识被阻止时）
当出现以下情况时触发正式投票：
- 在懒惰共识期间工作组成员阻止
- 负责人或三名或更多工作组成员请求正式投票
投票规则：
- 法定人数：50% 的活跃工作组成员
- 通过：常规事项简单多数；范围变更需 2/3 多数
- 核心维护者反馈是咨询性的，除非明确声明为具有约束力
- 所有投票均记录理由
步骤 3：升级（当投票无法解决时）
如果投票未能解决事项（无法定人数、未通过或结果有争议），负责人按照下面定义的升级路径升级给核心维护者。
1.5 升级路径
对于群组范围内的技术和设计分歧，群组应在涉及核心维护者之前在本地解决分歧。对于工作组，这意味着使用决策流程（懒惰共识 → 投票 → 升级）。对于兴趣小组，协调人应在升级前尝试找到粗略共识。
有些分歧不适合群组级解决，应直接升级给核心维护者：
- 范围争议（主题是否属于群组章程范围内）
- 权限争议（群组是否有权决定事项）
- 跨群组冲突（跨越多个工作组或兴趣小组的分歧）
- 行为准则或行为问题
- 成员资格或参与争议
当需要升级时：
- 负责人记录决策、考虑的选项和分歧点
- 负责人向核心维护者群组提出升级，并提出明确的请求
- 核心维护者群组指定一名核心维护者——该人员不应与涉及方有组织隶属关系——以解决问题并向群组报告
- 指定的核心维护者要么：(a) 提供具有约束力的指导，(b) 请求更多信息，或 (c) 建议全体核心维护者群组审议
- 时间表：升级应在 5 个工作日内收到初步响应
1.6 会议要求
负责人根据群组当前的需求和生命周期阶段确定会议频率、格式和时长。没有固定的节奏要求——接近规范发布的工作组可能每周开会，而早期探索阶段的兴趣小组可能每月开会或主要异步工作。
无论格式或频率如何，所有群组会议必须：
负责人应积极让工作组成员和参与者参与运营职责，如准备议程、记录会议笔记和主持讨论。
1.7 沟通渠道
所有群组使用以下渠道：
| 渠道 | 目的 | 响应预期 |
|---|
Discord #{name}-wg 或 #{name}-ig | 快速问题、协调 | 尽力而为 |
| GitHub Discussions | 长篇技术讨论 | 每周分类 |
1.8 报告
工作组 提供季度更新（1 月、4 月、7 月、10 月底），包括：
- 对照交付物的进度
- 受阻事项和升级
- 成员变更
- upcoming 优先事项
- 资源需求
季度更新作为文档发布在工作组的 GitHub Discussions 类别中。它们可选择在核心维护者会议上与核心维护者讨论。
兴趣小组 没有正式的报告要求，但应保持其章程和成员列表最新。
1.9 生命周期
工作组成立：
- There must be a widely acknowledged concern requiring coordination
- PR for creation of WG into
docs/community/<name>/overview.mdx, gated by CODEOWNERS requiring approval by Maintainers
- PR for charter into
docs/community/<name>/charter.mdx, gated by CODEOWNERS requiring approval from a single Core Maintainer (who should notify all Core Maintainers)
- Initial member list approved by WG Lead
兴趣小组成立：
- 在 Discord 的
#wg-ig-group-creation 频道中填写创建模板
- 核心维护者审查提案；兴趣小组及其协调人必须由至少两名核心维护者或一名首席维护者赞助
- 一旦获得赞助，协调人组织兴趣小组并创建章程
退休：
- 工作组：工作组负责人或核心维护者提出退休及理由；需要核心维护者或首席维护者批准。当工作组在一段时间内没有活跃工作或已完成所有计划的交付物时，也会退休。
- 兴趣小组：核心维护者或首席维护者可以退休不再活跃或不再需要的兴趣小组。
- 在这两种情况下，文档都会被归档，渠道标记为非活动。
1.10 章程修订
群组章程（工作组或兴趣小组）的变更需要：
- 由负责人/协调人或核心维护者提出
- 由核心维护者批准
第二部分：章程模板
每个 MCP 工作组和兴趣小组必须维护遵循此模板结构的章程文档。章程作为 MDX 文件存储在 modelcontextprotocol 仓库的 docs/community/<group-name>/charter.mdx 处，并添加到 docs/docs.json 文件中。此模板的可复制版本发布在 docs/community/charter-template.mdx。
章程捕获特定于每个群组的信息。第一部分的治理规则自动适用，无需在章程中重复。标记为 (仅限工作组) 的部分是工作组必需的，但对于兴趣小组是可选的。
1. 群组类型
说明这是 工作组 还是 兴趣小组。
2. 使命陈述
用 2-3 句话总结群组的目的，阐述：
- 正在解决的问题空间
- 为什么需要跨领域协作
- 对于工作组：群组将产出的具体交付物
- 对于兴趣小组：群组将促进的讨论和知识共享
工作组示例：
传输工作组致力于演进 MCP 的传输机制，以支持多样化的部署场景——从本地子进程通信到水平扩展的云部署——同时保持协议一致性和向后兼容性。
兴趣小组示例：
企业兴趣小组探索在企业环境中部署 MCP 的挑战，收集用例和需求以为未来的规范工作提供信息。
3. 范围
范围内：枚举的职责。
对于工作组，包括：
- 规范工作：拥有的特定规范部分或 SEP
- 参考实现方案：SDK 组件或参考实现方案
- 跨领域关注点：需要与其他群组协调的领域
- 文档：文档职责
对于兴趣小组，包括：
范围外：明确声明不在群组职权范围内的内容，以防止使命蔓延。
相关群组：列出工作相交的其他工作组或兴趣小组及重叠性质。
4. 领导层
负责人/协调人 表格，包含：
领导要求和职责在治理规则中定义（第 1.1 和 1.2 节）。
5. 权限与决策权 (仅限工作组)
每个工作组必须明确定义其决策权限。决策流程和升级路径在治理规则中定义（第 1.4 和 1.5 节）。本节记录工作组可以在哪个权限级别做出哪些决策。
示例：
| 决策类型 | 权限级别 |
|---|
| 会议后勤与调度 | 工作组负责人（自主） |
| 工作组内的提案优先级 | 工作组负责人（自主） |
| SEP 分类与关闭（范围内） | 工作组负责人（自主，需有文档记录的理由） |
| 范围内的技术设计 | 工作组共识 |
| 规范变更（增量） | 工作组共识 → 核心维护者批准 |
| 规范变更（破坏性/根本性） | 工作组共识 → 核心维护者批准 + 更广泛的审查 |
| 范围扩展 | 需要核心维护者批准 |
| 工作组成员批准 | 工作组成员赞助 |
6. 成员资格
列出当前群组成员及其参与层级（如果有）。如果尚无成员则省略。
参与层级和成员资格标准在治理规则中定义（第 1.3 节）。
7. 运作
记录群组当前的会议方法。会议要求和沟通渠道在治理规则中定义（第 1.6 和 1.7 节）。
示例：
| 会议 | 频率 | 时长 | 目的 |
|---|
| 工作会议 | 每周/每两周 | 60 分钟 | 技术讨论、提案审查 |
| 办公时间 | 每月 | 30 分钟 | 面向新人和观察者的开放问答 |
8. 交付物与成功指标 (仅限工作组)
活跃工作项：
| 项目 | 状态 | 目标日期 | 负责人 |
|---|
| SEP-XXX: 名称 | 草稿/审查/已批准 | 日期 | 姓名 |
9. 变更日志
跟踪章程版本，包含日期和变更。
为什么要将治理与章程模板分开？
将固定的治理规则与每个组的章程模板分开，可以明确哪些是所有组一致的（决策、成员层级、升级机制），哪些是每个组自行定义的（范围、领导名单、交付物）。这防止了组在流程上意外偏离，同时在重要的地方保留了灵活性。
为什么要涵盖工作组和兴趣组？
工作组和兴趣组服务于不同的目的，但共享共同的运营需求——领导层、会议要求、沟通渠道和升级路径。统一的治理框架确保了一致性，同时清晰地阐述了兴趣组有哪些较轻的要求（无正式决策权、无交付物跟踪、无季度报告）。
为什么要使用标准化模板？
标准化：
- 确保所有组都解决关键的治理问题
- 使社区成员更容易理解任何组的运营
- 减少组建新组的开销
- 通过明确的文档建立问责制
为什么要明确权限表？
权限表直接解决了“权限不明确”的反馈。通过列举决策类型和所需的批准，工作组和社区成员确切地知道什么可以自主决定，什么需要升级。兴趣组免除此要求，因为它们产生的是建议，而非绑定决策。
为什么要分级参与？
不同的参与级别服务于不同的社区需求：
- 观察者 可以在没有承诺的情况下学习
- 参与者 可以在不承担完整工作组成员责任的情况下贡献
- 工作组成员 承担责任并获得决策权（主要是工作组）
- 负责人/协调人 提供运营连续性
为什么默认采用懒惰共识？
懒惰共识：
- 使常规事项的高效决策成为可能
- 减少会议负担
- 通过公告/截止日期结构记录决策
- 保留对实质性问题的阻止权
投票保留用于有争议或高影响的决策。
模型灵感
此模板改编自 Kubernetes 治理结构，并根据通过社区访谈确定的 MCP 特定需求进行了定制。
向后兼容性
现有组的过渡
在本 SEP 被接受时存在的工作组和兴趣组将被保留——它们被认可为有效组，不需要通过第 1.9 节中定义的组建流程重新申请。
但是，现有组必须在本 SEP 被接受后的 8 周 内创建符合第 2 部分模板的章程。在此过渡期间：
- 现有组继续在其当前流程下运营
- 负责人/协调人负责起草章程
- 核心维护者将审查并批准工作组和兴趣组的章程
- 未能在 8 周内产生章程的组将被视为不活跃，并面临退役
安全影响
无直接安全影响。但是，清晰的权限委派和决策流程通过确保决策在适当级别做出并具有适当的问责制，间接支持安全。
参考实现
本 SEP 通过以下方式实现：
docs/community/working-interest-groups.mdx — 治理规则（第 1 部分），作为 modelcontextprotocol.io 上的工作组和兴趣组页面发布docs/community/charter-template.mdx — 可复制的章程模板（第 2 部分），从上述页面链接- 两个页面都添加到
docs/docs.json 下的 Community → Governance 导航组中
- 现有工作组和兴趣组必须在接受后 8 周内在
docs/community/<name>/charter.mdx 创建符合要求的章程
