> ## Documentation Index
> Fetch the complete documentation index at: https://mcp-zh.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

* **状态（Status）**: Final
* **类型（Type）**: Process
* **创建（Created）**: 2025-01-15
* **作者（Author(s)）**: David Soria Parra (@dsp-ant), Sarah Novotny (@sarahnovotny)
* **担保人（Sponsor）**: David Soria Parra (@dsp-ant)
* **PR**: [https://github.com/modelcontextprotocol/specification/pull/2149](https://github.com/modelcontextprotocol/specification/pull/2149)

## 摘要

本 SEP 为 MCP 的两种协作群组类型确立治理规则和一套标准化章程模板：**工作组（WG）** 和 **兴趣组（IG）**。工作组产出具体的交付物——SEP、实现和代码。兴趣组促成讨论和知识分享，以识别问题并收集需求。治理规则定义所有群组必须遵循的要求，并在适当之处对 IG 有较轻的预期。章程模板定义每个群组用来记录其特定使命、范围、领导层和工作的结构。二者共同回应了社区关于权限委派不清和各群组流程不一致的反馈。

本 SEP 是 [SEP-2148：MCP 贡献者阶梯](./2148-contributor-ladder.md)的配套文件，后者定义了本文档中引用的组织范围贡献者角色（成员、维护者、核心维护者、首席维护者）。群组领导角色与贡献者阶梯相交：WG Lead 和 IG 主持人必须在阶梯上至少持有成员身份，而群组参与是通往阶梯晋升的一条受认可的路径。

## 动机

社区访谈和反馈识别出当前群组结构的若干挑战：

1. **权限不清**：工作组能自主作出哪些决策、哪些需要核心维护者批准，并不总是清晰。这导致犹豫和瓶颈。

2. **决策不一致**：不同群组以不同规范运作。在一次会议中作出的决策可能在另一次会议中被推翻，且没有清晰的解决流程。

3. **参与混乱**：社区成员不确定谁应参与群组、存在哪些参与级别，以及如何更深入地参与。

4. **范围蔓延**：没有明确的边界，群组可能逐渐扩张到其他群组拥有的领域或其职责之外。

5. **缺失的上报路径**：当群组陷入僵局时，没有清晰的解决路径，导致旷日持久的分歧或被放弃的倡议。

6. **WG/IG 区分**：工作组与兴趣组的区别对参与者并不总是清晰，导致对产出和投入的预期不匹配。

标准化的章程模板和共享的治理规则通过在所有群组间确立一致的流程、同时要求每个群组显式定义其特定范围和边界，来解决这些问题。

## 规范

MCP 维护两种协作群组类型：

* **工作组（WG）** 产出具体的交付物——SEP、参考实现和代码。期望积极贡献。
* **兴趣组（IG）** 围绕某个主题领域促成讨论和知识分享。它们产出问题陈述、用例和建议。期望积极贡献。

本规范有两部分：

1. **群组治理** —— 适用于所有 MCP 群组（WG 和 IG）的规则，凡有差异之处均注明
2. **章程模板** —— 每个群组填写以定义其特定使命、范围和运作的结构

***

### 第 1 部分：群组治理

以下规则适用于所有 MCP 工作组和兴趣组。个别章程不能覆盖这些要求。凡 WG 与 IG 之间规则不同之处，均明确注明。

#### 1.1 领导层

每个群组有一位或多位 **Lead**（对兴趣组称为 **Facilitator/主持人**）。

**对所有 Lead 和 Facilitator 的要求：**

* 在 [MCP 贡献者阶梯](./2148-contributor-ladder.md)上至少持有成员身份
* 已展现出对该群组范围领域的持续投入
* 有能力跨组织边界进行主持
* 承诺运营该群组的日常事务
* 群组及其领导层由至少两位核心维护者或一位首席维护者担保

**对 WG Lead 的额外要求：**

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

#### 1.2 领导层职责

**所有 Lead 负责：**

* 安排并主持例会
* 与参与者协作制定议程并提前发布
* 确保会议纪要在 48 小时内发布
* 维护该群组的文档
* 在 [https://github.com/modelcontextprotocol/access](https://github.com/modelcontextprotocol/access) 中维护一份成员列表和相应的访问列表
* 主动招募并留住跨组织、跨视角的广泛、有代表性的成员

**WG Lead 额外负责：**

* 通过 [SEP](https://modelcontextprotocol.io/community/sep-guidelines)（规范增强提案）流程推动提案走向裁决
* 分诊该 WG 范围领域内的 SEP，包括关闭不契合路线图的 SEP（附成文理由；作者可向核心维护者申诉）
* 将受阻的决策附清晰背景上报给核心维护者
* 维护该工作组的路线图
* 持续地就该群组的总体方向征求一位或多位核心维护者的反馈
* 向社区和核心维护者群体提供季度状态更新

#### 1.3 参与级别

所有群组使用以下参与层级。注意 **WG 成员** 是一个群组特定的参与级别，不同于[贡献者阶梯](./2148-contributor-ladder.md)中定义的组织范围 **成员** 角色——一个人可以在某个特定群组中是 WG 成员，而不持有组织范围的成员身份，反之亦然。

| 级别                   | 描述             | 权限                 |
| -------------------- | -------------- | ------------------ |
| **观察者**              | 任何有兴趣关注该群组工作的人 | 读取权限，可参加会议，有限的讨论参与 |
| **参与者**              | 群组讨论的积极贡献者     | 可提议议程条目，参与异步投票     |
| **WG 成员**            | 已展现出专业能力的持续贡献者 | 计入法定人数（仅 WG）       |
| **Lead/Facilitator** | 群组的运营领导        | 制定议程、主持、上报         |

兴趣组主要以观察者、参与者和主持人运作。如果 IG 的工作需要正式决策，可以采用 WG 成员层级，但并非必需。

**成为 WG 成员（WG，以及采用 WG 成员层级的 IG）：**

* 持续参与 3 个月以上
* 有意义的贡献（代码、规范文本、评审或文档）
* 由现有 WG 成员或 Lead 提名
* 7 天内 Lead、核心维护者或首席维护者无异议

**WG 成员职责：**

* 继续本着诚意贡献
* 在相应群组的成员列表中维护姓名、组织和 Discord 名称

**活跃 vs. 荣誉退任：** 连续 3 个月不参与的 WG 成员将被移至荣誉退任状态，并可通过展现重新参与而回归。

#### 1.4 决策流程

本节主要适用于作出有约束力决策（技术设计共识、规范变更等）的工作组。兴趣组通常在讨论中以粗略共识运作，不作出有约束力的决策——其产出是建议、问题陈述和用例。采用 WG 成员层级的 IG 可将此流程用于内部决策。

**WG 共识** 通过以下递进过程达成。每一步在进入下一步之前都会先尝试：

**第 1 步：惰性共识（默认）**

* 提案公布时附明确截止期限（次要事项至少 5 天，重大事项 10 天）
* 沉默即同意
* 任何 WG 成员可附成文异议进行阻止
* 阻止必须提出替代方案或明确的解决标准
* 若截止期限前无阻止，则提案被接受

**第 2 步：正式投票（当惰性共识被阻止时）**

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

* 某位 WG 成员在惰性共识期内进行阻止
* 一位 Lead 或三位及以上 WG 成员请求正式投票

投票规则：

* 法定人数：活跃 WG 成员的 50%
* 通过：常规事项简单多数；范围变更三分之二多数
* 除非明确声明为有约束力，核心维护者的反馈为建议性
* 所有投票附理由记录

**第 3 步：上报（当投票无法解决时）**

如果投票未能解决该事项（无法定人数、未通过，或结果有争议），Lead 按下方定义的上报路径上报给核心维护者。

#### 1.5 上报路径

对于群组范围内的技术和设计分歧，群组应在牵涉核心维护者之前于本地解决分歧。对于 WG，这意味着使用决策递进过程（惰性共识 → 投票 → 上报）。对于 IG，主持人应在上报之前尝试找到粗略共识。

有些分歧不适合在群组层面解决，应直接上报给核心维护者：

* 范围争议（某议题是否落在该群组章程内）
* 权限争议（该群组是否有权决定某事项）
* 跨群组冲突（跨越多个 WG 或 IG 的分歧）
* 行为准则或行为相关的关切
* 成员或参与争议

当有必要上报时：

1. Lead 记录该决策、所考虑过的选项和分歧点
2. Lead 将上报附一个清晰的诉求呈交给核心维护者群体
3. 核心维护者群体指定一位 CM——其不应与涉事各方有相同的组织隶属——来解决该问题并向群组反馈
4. 被指定的 CM 或者：(a) 提供有约束力的指导，(b) 请求更多信息，或 (c) 建议全体核心维护者群体审议
5. 时间线：上报应在 5 个工作日内获得初步回应

#### 1.6 会议要求

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

无论形式或频率如何，所有群组会议都必须：

* 向所有社区参与者开放（不得有封闭或组织内部的会议）
* 至少提前 7 天发布在 [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io) 上
* 有已发布且公开可用的议程。议程或其链接应作为 [Meeting Notes 分类下的 GitHub Discussion](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/) 发布
* 在 48 小时内将纪要发布到同一个讨论中

Lead 应积极让 WG 成员和参与者参与运营职责，例如准备议程、记录会议纪要和主持讨论。

#### 1.7 沟通渠道

所有群组使用以下渠道：

| 渠道                                  | 用途      | 响应预期 |
| ----------------------------------- | ------- | ---- |
| Discord `#{name}-wg` 或 `#{name}-ig` | 快速提问、协调 | 尽力而为 |
| GitHub Discussions                  | 长篇幅技术讨论 | 每周分诊 |

除 Discord 外，群组可以在 [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/) 中建立一个讨论分类。Lead 将被授予相应角色以管理和审核讨论。

#### 1.8 报告

**工作组** 提供季度更新（1 月、4 月、7 月、10 月底），包括：

* 对照交付物的进展
* 受阻条目和上报
* 成员变动
* 即将到来的优先事项
* 资源需求

季度更新以文档形式发布在该工作组的 [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/) 分类中。它们可选地在核心维护者会议上与核心维护者讨论。

**兴趣组** 没有正式的报告要求，但应保持其章程和成员列表最新。

#### 1.9 生命周期

**工作组组建：**

* 必须存在一个被广泛认可、需要协调的关切
* 提交一个 PR 将 WG 创建到 `docs/community/<name>/overview.mdx`，由 CODEOWNERS 把关、要求维护者批准
* 提交一个 PR 将章程放到 `docs/community/<name>/charter.mdx`，由 CODEOWNERS 把关、要求单个核心维护者批准（该维护者应通知所有核心维护者）
* 初始成员列表由 WG Lead 批准

**兴趣组组建：**

* 在 [Discord](https://discord.gg/6CSzBmMkjX) 的 `#wg-ig-group-creation` 频道填写创建模板
* 一位核心维护者评审该提案；IG 及其主持人必须由至少两位核心维护者或一位首席维护者担保
* 一经担保，主持人组织该 IG 并创建章程

**退役：**

* **WG**：WG Lead 或核心维护者附理由提议退役；需要核心维护者或首席维护者批准。当 WG 在持续一段时间内没有活跃工作，或已完成所有计划交付物时，也会被退役。
* **IG**：核心维护者或首席维护者可以退役一个不再活跃或不再需要的 IG。
* 两种情况下，文档都会被归档，频道会被标记为不活跃。

#### 1.10 章程修订

对群组章程（WG 或 IG）的更改需要：

* 由 Lead/Facilitator 或核心维护者提议
* 由核心维护者批准

***

### 第 2 部分：章程模板

每个 MCP 工作组和兴趣组都必须维护一份遵循此模板结构的章程文档。章程作为 MDX 文件存放在 modelcontextprotocol 仓库的 `docs/community/<group-name>/charter.mdx`，并添加到 `docs/docs.json` 文件。此模板的可复制版本发布于 [`docs/community/charter-template.mdx`](/community/charter-template)。

章程记录每个群组所特有的信息。第 1 部分的治理规则自动适用，无需在章程中重复。标记为 **（仅 WG）** 的章节对工作组是必需的，对兴趣组是可选的。

#### 1. 群组类型

说明这是一个 **工作组** 还是一个 **兴趣组**。

#### 2. 使命陈述

用 2-3 句话概括该群组的宗旨，阐明：

* 所要解决的问题领域
* 为何需要跨领域协作
* 对于 WG：该群组将产出哪些具体交付物
* 对于 IG：该群组将促成哪些讨论和知识分享

*WG 示例：*

> 传输工作组的存在是为了推动 MCP 的传输机制演进，以支持多样化的部署场景——从本地子进程通信到横向扩展的云部署——同时保持协议的一致性和向后兼容性。

*IG 示例：*

> 企业 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 可以在哪个权限层级作出哪些决策。

*示例：*

| 决策类型           | 权限层级                    |
| -------------- | ----------------------- |
| 会议事务与排期        | WG Leads（自主）            |
| WG 内提案优先级排序    | WG Leads（自主）            |
| SEP 分诊与关闭（范围内） | WG Leads（自主，附成文理由）      |
| 范围内的技术设计       | WG 共识                   |
| 规范变更（增量式）      | WG 共识 → 核心维护者批准         |
| 规范变更（破坏性/根本性）  | WG 共识 → 核心维护者批准 + 更广泛评审 |
| 范围扩展           | 需要核心维护者批准               |
| WG 成员批准        | WG 成员担保                 |

IG 不作出有约束力的决策，不需要此章节。

#### 6. 成员

列出现任群组成员及其参与级别（如有）。若尚无成员则省略。参与层级和成员资格标准在治理规则（第 1.3 节）中定义。

#### 7. 运作

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

*示例：*

| 会议   | 频率    | 时长    | 目的            |
| ---- | ----- | ----- | ------------- |
| 工作会议 | 每周/双周 | 60 分钟 | 技术讨论、提案评审     |
| 答疑时间 | 每月    | 30 分钟 | 面向新人和观察者的开放问答 |

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

**活跃工作项：**

| 条目          | 状态                    | 目标日期 | 牵头人 |
| ----------- | --------------------- | ---- | --- |
| SEP-XXX: 名称 | Draft/Review/Approved | 日期   | 姓名  |

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

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

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

#### 9. 变更日志

以日期和变更跟踪章程版本。

## 理由

### 为何将治理与章程模板分离？

将固定的治理规则与逐群组的章程模板分离，明确了什么在所有群组间保持一致（决策、成员层级、上报）与什么由每个群组自行定义（范围、领导名录、交付物）。这防止群组在流程上意外分歧，同时在重要之处保留灵活性。

### 为何同时涵盖 WG 和 IG？

工作组和兴趣组服务于不同的目的，但共享共同的运营需求——领导层、会议要求、沟通渠道和上报路径。统一的治理框架确保一致性，同时清晰地阐明 IG 在何处有较轻的要求（无正式决策权、无交付物跟踪、无季度报告）。

### 为何要标准化模板？

标准化：

* 确保所有群组处理关键的治理问题
* 让社区成员更容易理解任何群组的运作
* 减少组建新群组的开销
* 通过显式文档创造问责

### 为何要显式的权限表？

权限表直接回应了"权限不清"的反馈。通过枚举决策类型和所需批准，WG 和社区成员就确切地知道什么可以自主决定、什么需要上报。IG 豁免此项，因为它们产出建议，而非有约束力的决策。

### 为何要分层参与？

不同的投入级别服务于不同的社区需求：

* **观察者** 可以无承诺地学习
* **参与者** 可以在没有完整 WG 成员职责的情况下贡献
* **WG 成员** 承担问责并获得决策权（主要是 WG）
* **Lead/Facilitator** 提供运营连续性

### 为何以惰性共识为默认？

惰性共识：

* 为常规事项实现高效决策
* 减轻会议负担
* 通过公布/截止期限结构记录决策
* 为实质性关切保留阻止权

投票保留给有争议或高影响的决策。

### 模型灵感

本模板改编自 Kubernetes 治理结构，并针对通过社区访谈识别出的 MCP 特定需求作了定制。

## 向后兼容性

### 既有群组的过渡

在本 SEP 被接受时已存在的工作组和兴趣组被"祖父条款"纳入——它们被承认为有效群组，无需通过第 1.9 节定义的组建流程重新申请。

然而，既有群组必须在本 SEP 被接受后 **8 周**内创建一份符合第 2 部分模板的章程。在此过渡期间：

* 既有群组继续在其当前流程下运作
* Lead/Facilitator 负责起草章程
* 核心维护者将评审并批准 WG 和 IG 章程
* 8 周内未产出章程的群组将被视为不活跃并可能被退役

## 安全影响

无直接安全影响。然而，清晰的权限委派和决策流程通过确保决策在适当层级、以适当问责作出，间接支持了安全。

## 参考实现

本 SEP 通过以下方式实现：

1. `docs/community/working-interest-groups.mdx` —— 治理规则（第 1 部分）作为 modelcontextprotocol.io 上的"工作组和兴趣组"页面发布
2. `docs/community/charter-template.mdx` —— 可复制的章程模板（第 2 部分），从上述页面链接
3. 两个页面都添加到 `docs/docs.json` 的 Community → Governance 导航组下
4. 既有的 WG 和 IG 必须在接受后 8 周内于 `docs/community/<name>/charter.mdx` 创建符合规范的章程