> ## 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.

# 工作组和兴趣组

> 模型上下文协议社区内两种协作群组形式——工作组和兴趣组——的治理规则。

在 MCP 贡献者社区内，我们维护两种协作形式：**兴趣组（IG）** 和 **工作组（WG）**。

## 速查

|          | 兴趣组（IG）              | 工作组（WG）              |
| -------- | -------------------- | -------------------- |
| **宗旨**   | 识别并讨论问题              | 构建具体解决方案             |
| **产出**   | 问题陈述、用例、建议           | SEP、实现、代码            |
| **投入**   | 期望积极贡献               | 期望积极贡献               |
| **持续时间** | 只要议题相关就持续进行          | 直至交付物完成              |
| **领导层**  | 主持人（Facilitator）     | Lead                 |
| **决策**   | 粗略共识，无约束力            | 有约束力（惰性共识 → 投票 → 上报） |
| **示例**   | "MCP 中的安全" —— 讨论安全挑战 | "服务器身份" —— 实现身份验证    |

## 何时使用哪一种

**在以下情况加入兴趣组：**

* 你有一个问题，但不确定解决方案
* 你想探索某个想法是否有社区支持
* 你是 MCP 新人，想了解某个主题领域
* 你想分享用例和需求

**在以下情况加入工作组：**

* 你有一个具体的解决方案要实现
* 你已准备好编写代码或 SEP
* 你能定期投入时间进行积极开发
* 你想帮助构建某个特定特性

**典型流程**：在 IG 中讨论一个问题 → 验证它是否值得解决 → 组建或加入一个 WG 来构建解决方案 → 提交一个 SEP → 实现

## 兴趣组（IG）

**目标：** 促进对某个特定主题有共同兴趣的 MCP 贡献者之间的讨论和知识分享。焦点在于识别值得解决的问题并收集需求——而非构建解决方案。

**IG 做什么：**

* 在 Discord 频道主持讨论
* 举行例会以分享用例
* 记录问题陈述和需求
* 就应优先处理什么构建共识
* 为工作组和 SEP 提供输入

**示例：**

* MCP 中的安全
* MCP 中的授权
* 在企业环境中使用 MCP
* 托管 MCP 客户端的工具和实践

## 工作组（WG）

**目标：** 就一个 SEP、一系列相关 SEP，或一个官方认可的项目进行协作。WG 产出具体的交付物。

**WG 做什么：**

* 编写并迭代 SEP
* 构建参考实现
* 维护进行中的项目（Inspector、Registry、SDK）
* 推动特性从提案走向规范

**示例：**

* Registry
* Inspector
* 工具过滤（Tool Filtering）
* 服务器身份（Server Identity）

## 治理

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

### 领导层

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

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

* 在 MCP 贡献者阶梯上至少持有成员（Member）身份——角色定义见[治理](/community/governance)
* 已展现出对该群组范围领域的持续投入
* 有能力跨组织边界进行主持
* 承诺运营该群组的日常事务
* 群组及其领导层由至少两位核心维护者或一位首席维护者担保

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

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

**所有 Lead 负责：**

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

**WG Lead 额外负责：**

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

### 参与级别

所有群组使用以下参与层级。注意 **WG 成员（WG Member）** 是一个群组特定的参与级别，不同于组织范围的 **成员（Member）** 角色——一个人可以在某个特定群组中是 WG 成员，而不持有组织范围的成员身份，反之亦然。

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

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

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

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

**WG 成员职责：**

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

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

### 决策流程

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

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

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

  <Step title="正式投票（当惰性共识被阻止时）">
    当某位 WG 成员在惰性共识期内进行阻止，或当一位 Lead 或三位及以上 WG 成员请求时，触发正式投票。

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

  <Step title="上报（当投票无法解决时）">
    如果投票未能解决该事项（无法定人数、未通过，或结果有争议），Lead 按下方上报路径上报给核心维护者。
  </Step>
</Steps>

### 上报路径

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

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

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

当有必要上报时：

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

### 会议要求

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

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

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

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

### 沟通渠道

所有群组使用以下渠道：

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

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

### 报告

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

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

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

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

### 生命周期

**工作组组建：**

* 必须存在一个被广泛认可、需要协调的关切
* 提交一个 PR，将 WG 章程添加为 `docs/community/working-groups/<name>.mdx`，依据[群组章程模板](/community/charter-template)撰写，并在 `docs/docs.json` 中包含相应的导航条目，由 CODEOWNERS 把关、要求核心维护者批准
* 初始成员列表由 WG Lead 批准

**兴趣组组建：**

* 在 [Discord](https://discord.gg/6CSzBmMkjX) 的 `#wg-ig-group-creation` 频道填写创建模板
* 一位核心维护者评审该提案；IG 及其主持人必须由至少两位核心维护者或一位首席维护者担保
* 一经担保，主持人组织该 IG，并通过一个 PR 创建章程，将 `docs/community/interest-groups/<name>.mdx` 添加进来，依据同一模板撰写，并在 `docs/docs.json` 中包含相应的导航条目，由 CODEOWNERS 把关、要求核心维护者批准

**退役：**

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

### 章程修订

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

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

## 章程

每个 MCP 工作组和兴趣组都必须维护一份章程文档，记录其特定的使命、范围、领导层、成员和运作。上述治理规则自动适用，无需在章程中重复。

所需结构和一份可复制的模板参见[群组章程模板](/community/charter-template)。

## 常见问题

### 我如何参与为 MCP 做贡献？

这些群组提供了一条入门通道：

1. [加入 Discord](https://discord.gg/6CSzBmMkjX) 并关注与你相关的 IG。参加[线上会议](https://meet.modelcontextprotocol.io/)。参与讨论。
2. 主动帮忙承担运营职责——主持会议、准备议程、记录纪要。在 SEP 讨论中分享你的用例。
3. 当准备好动手工作时，为 WG 交付物做贡献。
4. 持续的贡献是通往 WG 成员身份和贡献者阶梯晋升的一条受认可的路径。

### 我在哪里能找到所有当前 WG 和 IG 的列表？

在 [MCP 贡献者 Discord](https://discord.gg/6CSzBmMkjX) 上，有一个为每个工作组和兴趣组设立的频道分区。获章程认可的群组在 [modelcontextprotocol 仓库](https://github.com/modelcontextprotocol/modelcontextprotocol)的 `docs/community/` 下也有文档。

### 我需要先加入一个 IG 才能启动一个 WG 吗？

不需要。IG 参与有助于验证想法和建立支持，但并非必需。如果你心中有明确的交付物并能获得核心维护者担保，可以直接提议一个 WG。

### 我需要身处某个 WG 才能提交 SEP 吗？

不需要。任何人都可以提交 SEP。不过，WG 协作可以强化你的提案并帮助它找到担保人。

### 如果我的 IG 讨论引出了一个具体的解决方案怎么办？

你可以：

* 组建一个新的 WG 来构建该解决方案
* 如果有覆盖该领域的现有 WG，则加入它
* 如果解决方案定义清晰，则直接提交一个 SEP

### 一个人可以身处多个 IG/WG 吗？

可以。在你时间允许的范围内参与尽可能多的群组。