MCP 社区
工作组与兴趣组

工作组与兴趣组

社区译文；来源： MCP 80041ab0

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

快速参考

兴趣组（IG）工作组（WG）
目的识别并讨论问题构建具体解决方案
产出问题陈述、用例、建议SEP、实现、代码
投入应积极贡献应积极贡献
持续只要主题仍然相关即可持续直到交付物完成
领导FacilitatorLead
决策粗略共识，无约束力有约束力（懒共识 → 投票 → 上报）
示例“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 身份；角色定义参见治理
  • 已证明持续参与该小组的范围领域
  • 能够跨组织促进协作
  • 承诺负责小组运营
  • 小组及其领导层由至少两名 Core Maintainer 或一名 Lead Maintainer 发起

WG Lead 的附加要求：

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

所有 Lead 负责：

  • 安排并促进定期会议
  • 与参与者共同制定议程，并提前发布
  • 确保会议记录在 48 小时内发布
  • 维护小组文档
  • 在访问仓库 中维护小组成员列表及相应访问列表
  • 主动招募并保留跨组织、跨观点、广泛且具有代表性的成员

WG Lead 还负责：

  • 推动提案通过 SEP 流程 直至作出决定
  • 分类处理 WG 范围内的 SEP，包括关闭不符合路线图的 SEP（必须记录理由；作者可以向 Core Maintainer 申诉）
  • 向 Core Maintainer 上报受阻决定，并提供清晰背景
  • 维护工作组路线图
  • 持续就小组整体方向向一名或多名 Core Maintainer 征求反馈
  • 每季度向社区和 Core Maintainer Group 提供状态更新

参与等级

所有小组使用以下参与等级。请注意，WG Member 是特定小组的参与等级，与整个组织的 Member 角色不同；个人可以在特定小组中是 WG Member 而不具备组织级 Member 身份，反之亦然。

等级说明权限
Observer对关注小组工作感兴趣的任何人读取权限、可以参加会议、有限参与讨论
Participant积极参与小组讨论的贡献者可以提议议程事项、参与异步投票
WG Member持续贡献且已证明专业能力的贡献者计入法定人数（仅 WG）
Lead/Facilitator小组运营领导者制定议程、促进协作、上报

兴趣组主要由 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 状态，并可通过证明重新参与恢复。

决策流程

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

WG 共识按以下顺序达成。进入下一步前，先尝试当前步骤。

懒共识（默认）

  • 公布提案并明确截止时间（小事项至少 5 天，重大事项至少 10 天）
  • 沉默即同意
  • 任何 WG Member 都可以提出有记录的反对并阻止提案
  • 阻止提案时必须提出替代方案或明确的解决标准
  • 截止时无人阻止，则提案被接受

正式投票（懒共识受阻时）

如果 WG Member 在懒共识期间阻止提案，或者 Lead 或至少三名 WG Member 要求投票，则启动正式投票。

  • 法定人数：活跃 WG Member 的 50%
  • 通过条件：常规事项采用简单多数；范围变更采用三分之二多数
  • Core Maintainer 的反馈仅为建议，除非明确说明具有约束力
  • 所有投票及理由都必须记录

上报（投票未解决时）

如果投票未能解决问题（未达到法定人数、未通过或结果有争议），Lead 按下述上报路径将问题上报 Core Maintainer。

上报路径

对于小组范围内的技术和设计分歧，小组应先在本地解决，再请 Core Maintainer 介入。对 WG 而言，应采用上述决策顺序。对 IG 而言，Facilitator 应先尝试形成粗略共识，再上报。

某些分歧不适合由小组层面解决，应直接上报 Core Maintainer：

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

需要上报时：

  1. Lead 记录决定、考虑过的选项和分歧点
  2. Lead 向 Core Maintainer 小组提出上报，并说明明确诉求
  3. Core Maintainer 小组指定一名 CM 解决问题并向小组反馈；该 CM 不应与争议方具有共同组织隶属关系
  4. 指定 CM 可以：(a) 给出有约束力的指导，(b) 要求更多信息，或 (c) 建议完整 Core Maintainer 小组讨论
  5. 时间线：上报应在 5 个工作日内获得初步响应

会议要求

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

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

Lead 应积极让 WG Member 和 Participant 参与准备议程、记录会议和促进讨论等运营工作。

沟通渠道

所有小组使用以下渠道：

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

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

报告

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

  • 交付物进展
  • 受阻事项和上报
  • 成员变更
  • 后续优先事项
  • 资源需求

季度更新以文档形式发布到工作组的 GitHub Discussions 类别中，也可以选择在核心维护者会议上与 Core Maintainer 讨论。

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

生命周期

组建工作组：

  • 必须存在一个公认需要协调的问题
  • 创建 PR，将 WG 章程添加为 docs/community/working-groups/<name>.mdx；章程按小组章程模板（英文） 编写，并在 docs/docs.json 中加入相应导航条目；通过 CODEOWNERS 要求 Core Maintainer 批准
  • 初始成员列表由 WG Lead 批准

组建兴趣组：

  • 在 Discord 的 #wg-ig-group-creation 频道填写创建模板
  • 由 Core Maintainer 评审提案；IG 及其 Facilitator 必须由至少两名 Core Maintainer 或一名 Lead Maintainer 发起
  • 获得发起支持后，Facilitator 组织 IG，并通过 PR 添加 docs/community/interest-groups/<name>.mdx 来创建章程；章程按同一模板编写，并在 docs/docs.json 中加入相应导航条目；通过 CODEOWNERS 要求 Core Maintainer 批准

终止：

  • WG：由 WG Lead 或 Core Maintainer 提出终止及理由，并需 Core Maintainer 或 Lead Maintainer 批准。长期没有活跃工作或已完成全部计划交付物的 WG 也会终止。
  • IG：Core Maintainer 或 Lead Maintainer 可以终止不再活跃或不再需要的 IG。
  • 两种情况下，文档都会归档，频道会标记为不活跃。

章程修订

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

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

章程

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

有关必需结构和可复制模板，参见小组章程模板（英文） 。

常见问题

如何开始为 MCP 作贡献？

这些小组提供了参与路径：

  1. 加入 Discord ，关注与你相关的 IG，参加线上会议 ，参与讨论。
  2. 主动协助运营工作，例如促进会议、准备议程和记录会议。在 SEP 讨论中分享用例。
  3. 准备好动手后，为 WG 交付物作贡献。
  4. 持续贡献是获得 WG Member 身份和在贡献者阶梯中晋升的公认路径。

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

MCP Contributor Discord 中为每个工作组和兴趣组设置了频道分区。已有章程的小组也在 modelcontextprotocol 仓库 的 docs/community/ 下维护文档。

启动 WG 前必须先加入 IG 吗？

不需要。参与 IG 有助于验证想法并建立支持，但不是必需条件。如果已有明确交付物，并能获得 Core Maintainer 发起支持，可以直接提议组建 WG。

提交 SEP 必须加入 WG 吗？

不需要。任何人都可以提交 SEP，不要求具备小组成员资格。不过，按照 SEP 指南 ，在创建 SEP pull request 前仍必须将提案带到相关小组的 Discord 频道。除此项要求外，与 WG 更紧密地协作可以增强提案，并帮助它找到发起人。

如果 IG 讨论形成了具体解决方案怎么办？

可以：

  • 组建新的 WG 来构建解决方案
  • 如果现有 WG 涵盖该领域，则加入该 WG
  • 如果解决方案定义明确，则直接提交 SEP

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

可以。在时间允许的范围内参加任意数量的小组。

反垄断政策功能生命周期与弃用政策