跳到主要内容
在 MCP 贡献者社区中，我们维护两种协作形式：兴趣小组 (IGs) 和 工作组 (WGs)。

​
快速参考

兴趣小组 (IG)工作组 (WG)
目的识别并讨论问题构建具体的解决方案
输出问题陈述、用例、建议SEP、实现方案、代码
承诺期望积极参与期望积极参与
时长只要话题相关就持续进行直至交付物完成
领导层引导人 (Facilitator)负责人 (Lead)
决策粗略共识，无约束力具约束力（惰性共识 → 投票 → 升级）
示例“MCP 中的安全性” — 讨论安全挑战“服务器身份” — 实现身份验证

​
如何选择

加入兴趣小组，当您：
  • 有疑问但尚不确定解决方案
  • 想探索一个想法是否得到社区支持
  • 是 MCP 新手并想了解某个主题领域
  • 想分享用例和需求
加入工作组，当您：
  • 有具体的解决方案需要实现
  • 准备编写代码或 SEP
  • 能够投入固定时间进行积极开发
  • 想帮助构建特定功能
典型流程：在 IG 中讨论问题 → 验证其是否值得解决 → 组建或加入 WG 以构建解决方案 → 提交 SEP → 实现

​
兴趣小组 (IGs)

目标：促进对特定主题有共同兴趣的 MCP 贡献者之间的讨论和知识共享。重点是识别值得解决的问题并收集需求，而非构建解决方案。 IG 的工作内容：
  • 在 Discord 频道主持讨论
  • 举办定期会议以分享用例
  • 记录问题陈述和需求
  • 就优先级排序达成共识
  • 向工作组和 SEP 提供意见
示例
  • MCP 中的安全性
  • MCP 中的身份验证
  • 在企业环境中使用 MCP
  • 托管 MCP 客户端的工具和实践

​
工作组 (WGs)

目标：针对一份 SEP、一系列相关 SEP 或官方认可的项目进行协作。WG 产出具体交付物。 WG 的工作内容：
  • 编写并迭代 SEP
  • 构建参考实现
  • 维护持续进行的项目（Inspector、Registry、SDKs）
  • 推动功能从提案走向规范
示例
  • 注册表 (Registry)
  • 检查器 (Inspector)
  • 工具过滤
  • 服务器标识

​
治理

以下规则适用于所有 MCP 工作组和兴趣小组。个别小组的章程不得违反这些要求。如 WG 和 IG 规则有所不同，将明确注明。

​
领导层

每个小组有一名或多名负责人（兴趣小组称为引导人）。 所有负责人和引导人的要求：
  • 在 MCP 贡献者阶梯中至少拥有成员身份 —— 角色定义请参阅治理
  • 在小组涵盖的领域中展现出持续的投入
  • 具备跨组织边界的协调能力
  • 致力于运营小组工作
  • 小组及其领导层需至少得到两名核心维护者或一名主要维护者的赞助
WG 负责人的额外要求
  • 每周投入 2-3 小时用于 WG 活动
所有负责人的职责：
  • 安排并主持定期会议
  • 与参与者合作设定议程并提前发布
  • 确保在 48 小时内发布会议纪要
  • 维护小组文档
  • 在 访问权限仓库 中维护成员列表及对应的权限列表
  • 积极招募并保留跨组织、多视角的广泛且具代表性的成员
WG 负责人的额外职责：
  • 推动提案通过 SEP 流程 直至解决
  • 对 WG 范围内的 SEP 进行分类，包括关闭不符合路线图的 SEP（需记录依据；作者可向核心维护者申诉）
  • 将受阻的决策以清晰的背景信息升级给核心维护者
  • 维护工作组的路线图
  • 持续从一名或多名核心维护者处获取关于小组总体方向的反馈
  • 向社区和核心维护者组提供季度状态更新

​
参与层级

所有小组均使用以下参与层级。请注意，WG 成员是特定于小组的参与层级，不同于组织范围的成员 (Member) 角色 —— 一个人可能在特定小组中是 WG 成员，但不具备组织范围的成员身份，反之亦然。
级别描述权限
观察者 (Observer)任何对跟踪小组工作感兴趣的人只读权限，可参加会议，有限的讨论参与度
参与者积极参与小组讨论的贡献者可提议议程事项，参加异步投票
WG 成员具有专业知识的持续贡献者计入法定人数（仅限 WG）
负责人/引导人 (Lead/Facilitator)小组的运营领导者设定议程、主持、处理升级
兴趣小组主要由观察者、参与者和引导人运作。IG 可采纳 WG 成员层级（如果其工作需要正式决策），但不是必须的。 成为 WG 成员（适用于 WG 及采纳了 WG 成员层级的 IG）：
  • 持续参与 3 个月以上
  • 有实质性贡献（代码、规范文档、评审或文档编制）
  • 由现任 WG 成员或负责人提名
  • 7 天内无负责人、核心维护者或主要维护者反对
WG 成员职责
  • 继续真诚地做出贡献
  • 在各自小组的成员列表中维护姓名、所属机构和 Discord 用户名
活跃与荣休：连续 3 个月未参与的 WG 成员将被转为荣休状态，可通过证明重新参与来回归。

​
决策流程

本节主要适用于做出具约束力决策（对技术设计、规范变更等的共识）的工作组。兴趣小组通常在讨论中通过粗略共识运作，不做出具约束力决策 —— 其输出为建议、问题陈述和用例。采纳了 WG 成员层级的 IG 可在内部决策中使用此流程。 WG 共识通过以下流程达成。每一步都会在进入下一步前尝试。
1

惰性共识 (Lazy Consensus, 默认)

  • 提案宣布并明确截止日期（次要事项至少 5 天，重大事项 10 天）
  • 沉默即同意
  • 任何 WG 成员均可通过记录在案的反对意见进行阻止
  • 反对者必须提出替代方案或明确的解决标准
  • 若截止日期前无人反对，则提案通过
2

正式投票（当惰性共识被阻止时）

当 WG 成员在惰性共识期间提出异议，或负责人或三名及以上 WG 成员要求时，触发正式投票。
  • 法定人数：活跃 WG 成员的 50%
  • 通过标准：常规事项简单多数；范围变更需 2/3 多数
  • 核心维护者的反馈仅作建议，除非明确声明为具约束力
  • 所有投票均需记录理由
3

升级（当投票无法解决问题时）

如果投票未能解决问题（无法达到法定人数、未通过或结果受到质疑），负责人需按下方升级路径向核心维护者升级。

​
升级路径

针对小组范围内的技术和设计分歧，小组应在引入核心维护者前尝试内部解决。对于 WG，这意味着使用上述决策流程。对于 IG，引导人应在升级前尝试达成粗略共识。 某些分歧不适合小组层面解决，应直接升级给核心维护者：
  • 范围争议（某个话题是否属于小组章程）
  • 权威争议（小组是否有权决定某事）
  • 跨组冲突（涉及多个 WG 或 IG 的分歧）
  • 行为准则或行为相关问题
  • 成员资格或参与争议
升级的必要程序
  1. 负责人记录决策、考虑过的选项及分歧点
  2. 负责人向核心维护者组提交升级请求，并明确具体诉求
  3. 核心维护者组指派一名核心维护者（应与涉事各方无组织关联）来解决问题并向小组汇报
  4. 被指派的 CM 要么：(a) 提供具有约束力的指导，(b) 要求更多信息，或 (c) 建议核心维护者全体讨论
  5. 时间线：升级应在 5 个工作日内得到初步响应

​
会议要求

负责人根据小组当前需求和生命周期阶段确定会议频率、形式和时长。没有固定的节奏要求 —— 处于规范发布期的 WG 可能每周开会，而处于早期探索阶段的 IG 可能每月开会或主要进行异步工作。 无论何种形式或频率，所有小组会议必须： 负责人应积极让 WG 成员和参与者分担运营工作，如准备议程、记录会议纪要和促进讨论。

​
沟通渠道

所有小组均使用以下渠道
频道目的响应预期
Discord #{name}-wg 或 #{name}-ig简单问题，协调尽力而为
GitHub Discussions（讨论区）长篇技术讨论每周分类
除 Discord 外，小组可在 GitHub Discussions 中建立讨论分类。负责人将被授予相应的管理和审核权限。

​
报告制度

工作组每季度提供更新（1 月、4 月、7 月、10 月末），内容包括：
  • 交付物的进展情况
  • 受阻事项和升级情况
  • 成员变动
  • 未来优先级
  • 资源需求
季度更新以文档形式发布在工作组的 GitHub Discussions 中。这些更新可选择在核心维护者会议上与核心维护者进行讨论。 兴趣小组没有正式报告要求，但应保持章程和成员列表的最新状态。

​
生命周期

工作组组建
  • 必须存在一个需要协调的、被广泛承认的关注点
  • 提交 PR 创建 WG，路径为 docs/community/working-groups/<name>/overview.mdx，由 CODEOWNERS 限制，需维护者审批
  • 提交 PR 创建章程，路径为 docs/community/working-groups/<name>.mdx，由 CODEOWNERS 限制，需核心维护者审批
  • 初始成员列表需经 WG 负责人批准
兴趣小组组建
  • 在 Discord 的 #wg-ig-group-creation 频道中填写创建模板
  • 核心维护者审查提案；IG 及其引导人必须由至少两名核心维护者或一名主要维护者赞助
  • 获得赞助后，引导人组建 IG 并起草章程
解散
  • WG：WG 负责人或核心维护者提出解散并说明理由；需核心维护者或主要维护者批准。WG 在长期无活跃工作或完成所有计划交付物后也会被解散。
  • IG：核心维护者或主要维护者可解散不再活跃或不再需要的 IG。
  • 在这两种情况下，文档会被存档，频道会被标记为不活跃。

​
章程修订

对小组章程（WG 或 IG）的变更要求：
  • 由负责人/引导人或核心维护者提议
  • 经核心维护者批准

​
章程

每个 MCP 工作组和兴趣小组必须维护一份章程文档，以记录其具体使命、范围、领导层、成员资格和运作方式。上述治理规则自动适用，无需在章程中重复。 所需结构及可复制模板请参阅 小组章程模板。

​
常见问题

​
我该如何参与 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
  • 如果解决方案定义明确，直接提交 SEP

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

可以。根据您的时间安排参与尽可能多的小组。