工作组与兴趣组

在 MCP 贡献者社区内，我们维持两种协作格式：兴趣组 (IG) 和 工作组 (WG)。

​

快速参考

​

何时使用哪种

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

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

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

• 有具体的解决方案需要实施
• 准备好编写代码或 SEP
• 能够承诺定期时间进行主动开发
• 想要帮助构建特定功能

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

​

兴趣组 (IG)

目标： 促进对特定主题感兴趣的 MCP 贡献者之间的讨论和知识共享。重点是识别值得解决的问题并收集需求——而不是构建解决方案。 兴趣组的工作内容：

• 在 Discord 频道中主持讨论
• 召开定期会议分享用例
• 记录问题陈述和需求
• 就优先事项建立共识
• 为工作组和 SEP 提供输入

示例：

• MCP 中的安全
• MCP 中的认证
• 在企业环境中使用 MCP
• 托管 MCP 客户端的工具和实践

​

工作组 (WG)

目标： 协作处理 SEP、一系列相关的 SEP 或官方认可的项目。工作组产生具体的交付物。 工作组的工作内容：

• 编写和迭代 SEP
• 构建参考实现
• 维护正在进行的项目（Inspector、Registry、SDKs）
• 推动功能从提案到规范

示例：

• Registry
• Inspector
• 工具过滤
• 服务器身份

​

治理

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

​

领导层

每个组都有一个或多个 负责人（对于兴趣组称为 协调人）。 所有负责人和协调人的要求：

• 在 MCP 贡献者阶梯上至少持有成员身份——参见 治理 了解角色定义
• 证明与该组范围领域有持续的参与
• 能够跨组织边界进行协调
• 承诺运行组的运营
• 组及其领导层由至少两名核心维护者或一名首席维护者担保

工作组负责人的额外要求：

• 承诺每周 2-3 小时用于工作组活动

所有负责人负责：

• 安排和主持定期会议
• 与参与者协作设置议程并提前发布
• 确保会议笔记在 48 小时内发布
• 维护组的文档
• 在 access 仓库 中维护成员列表和相应的访问列表
• 主动招募和保留跨组织和观点的广泛、代表性成员

工作组负责人还负责：

• 通过 SEP 流程 推动提案直至解决
• 处理工作组范围内的 SEP，包括关闭不符合路线图的 SEP（需有文档记录的理由；作者可向核心维护者上诉）
• 将受阻的决策升级给核心维护者，并提供清晰的背景
• 维护工作组的路线图
• 持续向一名或多名核心维护者征求关于组总体方向的反馈
• 向社区和核心维护者组提供季度状态更新

​

参与层级

所有组使用以下参与层级。请注意，工作组成员 是特定于组的参与层级，不同于组织范围的 成员 角色——个人可以在特定组中成为工作组成员而不持有组织范围的成员身份，反之亦然。 兴趣组主要与观察者、参与者和协调人一起运作。如果兴趣组的工作需要正式决策，可以采用工作组成员层级，但不是必须的。 成为工作组成员（工作组，以及采用工作组成员层级的兴趣组）：

• 持续参与超过 3 个月
• 有意义的贡献（代码、规范文本、审查或文档）
• 由现有工作组成员或负责人提名
• 7 天内负责人、核心维护者或首席维护者无异议

工作组成员职责：

• 继续诚信贡献
• 在相应组的成员列表中维护姓名、组织和 Discord 名称

活跃与名誉：连续 3 个月未参与的工作组成员将转为名誉状态，并可通过证明重新参与而回归。

​

决策流程

本节主要适用于工作组，工作组做出具有约束力的决策（关于技术设计、规范变更等的共识）。兴趣组通常在讨论中通过大致共识运作，不做具有约束力的决策——他们的产出是建议、问题陈述和用例。采用工作组成员层级的兴趣组可以使用此流程进行内部决策。 工作组共识 通过以下 progression 达成。在进入下一步之前尝试每一步。

​

升级路径

对于组范围内的技术和设计分歧，组应在涉及核心维护者之前在本地解决分歧。对于工作组，这意味着使用上述决策流程。对于兴趣组，协调人应在升级前尝试找到大致共识。 有些分歧不适合组级解决，应直接升级给核心维护者：

• 范围争议（主题是否属于组的章程范围）
• 权限争议（组是否有权决定事项）
• 跨组冲突（跨越多个工作组或兴趣组的分歧）
• 行为准则或行为问题
• 成员资格或参与争议

当需要升级时：

1. 负责人记录决策、考虑的选项和分歧点
2. 负责人向核心维护者组提出升级，并提出明确的请求
3. 核心维护者组指定一名核心维护者——该人员不应与涉及方有组织隶属关系——以解决问题并向组报告
4. 指定的核心维护者要么：(a) 提供具有约束力的指导，(b) 请求更多信息，或 (c) 建议全体核心维护者组审议
5. 时间表：升级应在 5 个工作日内收到初步响应

​

会议要求

负责人根据组的当前需求和生命周期阶段确定会议频率、格式和持续时间。没有固定的节奏要求——接近规范发布的工作组可能每周开会，而早期探索阶段的兴趣组可能每月开会或主要异步工作。 无论格式或频率如何，所有组会议必须：

• 向所有社区参与者开放（无封闭或组织内部会议）
• 至少提前 7 天发布在 meet.modelcontextprotocol.io
• 议程已发布并公开可用。议程或议程链接应作为 GitHub 讨论中的会议笔记类别 发布
• 笔记在 48 小时内发布到同一讨论

负责人应积极让工作组成员和参与者参与运营职责，如准备议程、记录会议笔记和主持讨论。

​

沟通渠道

所有组使用以下渠道： 除了 Discord，组还可以在 GitHub 讨论 中建立讨论类别。负责人将获得适当的角色来管理和 moderating 讨论。

​

报告

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

• 针对交付物的进度
• 受阻事项和升级
• 成员变更
• 即将到来的优先事项
• 资源需求

季度更新作为文档发布在工作组的 GitHub 讨论 类别中。它们可选择在核心维护者会议上与核心维护者讨论。 兴趣组 没有正式的报告要求，但应保持其章程和成员列表最新。

​

生命周期

工作组成立：

• 必须存在需要协调的广泛认可的关注点
• 将工作组创建为 docs/community/<name>/overview.mdx 的 PR，由 CODEOWNERS gating，需要维护者批准
• 将章程创建为 docs/community/<name>/charter.mdx 的 PR，由 CODEOWNERS gating，需要核心维护者批准
• 初始成员列表由工作组负责人批准

兴趣组成立：

• 在 Discord 的 #wg-ig-group-creation 频道中填写创建模板
• 核心维护者审查提案；兴趣组及其协调人必须由至少两名核心维护者或一名首席维护者担保
• 一旦担保，协调人组织兴趣组并创建章程

退休：

• 工作组：工作组负责人或核心维护者提出退休理由；需要核心维护者或首席维护者批准。当工作组在很长一段时间内没有活跃工作或已完成所有计划的交付物时，也会退休。
• 兴趣组：核心维护者或首席维护者可以退休不再活跃或不再需要的兴趣组。
• 在这两种情况下，文档被归档，渠道被标记为非活动。

​

章程修订

更改组的章程（工作组或兴趣组）需要：

• 由负责人/协调人或核心维护者提出提案
• 由核心维护者批准

​

章程

每个 MCP 工作组（Working Group）和兴趣小组（Interest Group）都必须维护一份章程文件，记录其特定的使命、范围、领导层、成员和运作方式。上述治理规则自动适用，无需在章程中重复。 请参阅 小组章程模板 以了解所需结构和可复制的模板。

​

常见问题

​

如何参与贡献 MCP？

这些小组提供了入门途径：

1. 加入 Discord 并关注与您相关的 IG。参加 在线会议。参与讨论。
2. 主动协助运营职责——主持会议、准备议程、做笔记。在 SEP 讨论中分享您的用例。
3. 当准备好进行实际工作时，为 WG 交付物做出贡献。
4. 持续贡献是获得 WG 成员身份和贡献者层级晋升的认可途径。

​

在哪里可以找到所有当前 WG 和 IG 的列表？

在 MCP 贡献者 Discord 上，每个工作组和兴趣小组都有一部分频道。拥有章程的小组在 modelcontextprotocol 仓库 的 docs/community/ 下也有文档。

​

在启动 WG 之前我需要加入 IG 吗？

不需要。参与 IG 可以帮助验证想法并获得支持，但这不是必需的。如果您心中有明确的交付物并能获得核心维护者的赞助，您可以直接提议成立 WG。

​

提交 SEP 我需要身在 WG 中吗？

不需要。任何人都可以提交 SEP。但是，WG 协作可以加强您的提案并帮助其找到赞助者。

​

如果我的 IG 讨论导致了具体的解决方案怎么办？

您可以：

• 成立一个新的 WG 来构建解决方案
• 如果已有覆盖该领域的 WG，加入现有的 WG
• 如果解决方案定义明确，直接提交 SEP

​

一个人可以加入多个 IG/WG 吗？

可以。根据您的时间允许，参与尽可能多的小组。