> ## Documentation Index > Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt > Use this file to discover all available pages before exploring further. # 工作组与兴趣组 > Model Context Protocol 社区内两种协作形式的治理规则——工作组和兴趣组。 在 MCP 贡献者社区内，我们维持两种协作格式：**兴趣组 (IG)** 和 **工作组 (WG)**。 ## 快速参考 | | 兴趣组 (IG) | 工作组 (WG) | | -------- | ------------------ | --------------------- | | **目的** | 识别并讨论问题 | 构建具体的解决方案 | | **产出** | 问题陈述、用例、建议 | SEP、实现、代码 | | **承诺** | 期望积极贡献 | 期望积极贡献 | | **持续时间** | 只要主题相关则持续 | 直到交付物完成 | | **领导层** | 协调人 | 负责人 | | **决策** | 大致共识，无约束力 | 具有约束力（懒惰共识 → 投票 → 升级） | | **示例** | "MCP 中的安全”——讨论安全挑战 | "服务器身份”——实现身份验证 | ## 何时使用哪种 **在以下情况时加入兴趣组：** * 有问题但不确定解决方案 * 想要探索某个想法是否有社区支持 * 是 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 贡献者阶梯上至少持有成员身份——参见 [治理](/community/governance) 了解角色定义 * 证明与该组范围领域有持续的参与 * 能够跨组织边界进行协调 * 承诺运行组的运营 * 组及其领导层由至少两名核心维护者或一名首席维护者担保 **工作组负责人的额外要求：** * 承诺每周 2-3 小时用于工作组活动 **所有负责人负责：** * 安排和主持定期会议 * 与参与者协作设置议程并提前发布 * 确保会议笔记在 48 小时内发布 * 维护组的文档 * 在 [access 仓库](https://github.com/modelcontextprotocol/access) 中维护成员列表和相应的访问列表 * 主动招募和保留跨组织和观点的广泛、代表性成员 **工作组负责人还负责：** * 通过 [SEP 流程](/community/sep-guidelines) 推动提案直至解决 * 处理工作组范围内的 SEP，包括关闭不符合路线图的 SEP（需有文档记录的理由；作者可向核心维护者上诉） * 将受阻的决策升级给核心维护者，并提供清晰的背景 * 维护工作组的路线图 * 持续向一名或多名核心维护者征求关于组总体方向的反馈 * 向社区和核心维护者组提供季度状态更新 ### 参与层级 所有组使用以下参与层级。请注意，**工作组成员** 是特定于组的参与层级，不同于组织范围的 **成员** 角色——个人可以在特定组中成为工作组成员而不持有组织范围的成员身份，反之亦然。 | 层级 | 描述 | 权限 | | ----------- | -------------- | ------------------ | | **观察者** | 任何有兴趣关注组工作的人 | 读取权限，可参加会议，有限的讨论参与 | | **参与者** | 组讨论的积极贡献者 | 可提议议程项目，参与异步投票 | | **工作组成员** | 具有证明专业知识的持续贡献者 | 计入法定人数（仅限工作组） | | **负责人/协调人** | 组的运营领导 | 设置议程、协调、升级 | 兴趣组主要与观察者、参与者和协调人一起运作。如果兴趣组的工作需要正式决策，可以采用工作组成员层级，但不是必须的。 **成为工作组成员**（工作组，以及采用工作组成员层级的兴趣组）： * 持续参与超过 3 个月 * 有意义的贡献（代码、规范文本、审查或文档） * 由现有工作组成员或负责人提名 * 7 天内负责人、核心维护者或首席维护者无异议 **工作组成员职责：** * 继续诚信贡献 * 在相应组的成员列表中维护姓名、组织和 Discord 名称 **活跃与名誉**：连续 3 个月未参与的工作组成员将转为名誉状态，并可通过证明重新参与而回归。 ### 决策流程 本节主要适用于工作组，工作组做出具有约束力的决策（关于技术设计、规范变更等的共识）。兴趣组通常在讨论中通过大致共识运作，不做具有约束力的决策——他们的产出是建议、问题陈述和用例。采用工作组成员层级的兴趣组可以使用此流程进行内部决策。 **工作组共识** 通过以下 progression 达成。在进入下一步之前尝试每一步。 * 提案宣布明确的截止日期（次要事项最少 5 天，重要事项 10 天） * 沉默即同意 * 任何工作组成员均可通过记录异议进行阻止 * 阻止必须提出替代方案或清晰的解决标准 * 如果在截止日期前未提出阻止，则提案被接受 当工作组成员在懒惰共识期间阻止，或当负责人或三名或更多工作组成员请求时，触发正式投票。 * 法定人数：50% 的活跃工作组成员 * 通过：常规事项简单多数；范围变更 2/3 多数 * 核心维护者反馈是咨询性的，除非明确说明为具有约束力 * 所有投票均记录理由 如果投票无法解决事项（无法定人数、未通过或结果有争议），负责人按照下面的升级路径升级给核心维护者。 ### 升级路径 对于组范围内的技术和设计分歧，组应在涉及核心维护者之前在本地解决分歧。对于工作组，这意味着使用上述决策流程。对于兴趣组，协调人应在升级前尝试找到大致共识。 有些分歧不适合组级解决，应直接升级给核心维护者： * 范围争议（主题是否属于组的章程范围） * 权限争议（组是否有权决定事项） * 跨组冲突（跨越多个工作组或兴趣组的分歧） * 行为准则或行为问题 * 成员资格或参与争议 当需要升级时： 1. 负责人记录决策、考虑的选项和分歧点 2. 负责人向核心维护者组提出升级，并提出明确的请求 3. 核心维护者组指定一名核心维护者——该人员不应与涉及方有组织隶属关系——以解决问题并向组报告 4. 指定的核心维护者要么：(a) 提供具有约束力的指导，(b) 请求更多信息，或 (c) 建议全体核心维护者组审议 5. 时间表：升级应在 5 个工作日内收到初步响应 ### 会议要求 负责人根据组的当前需求和生命周期阶段确定会议频率、格式和持续时间。没有固定的节奏要求——接近规范发布的工作组可能每周开会，而早期探索阶段的兴趣组可能每月开会或主要异步工作。 无论格式或频率如何，所有组会议必须： * 向所有社区参与者开放（无封闭或组织内部会议） * 至少提前 7 天发布在 [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io) * 议程已发布并公开可用。议程或议程链接应作为 [GitHub 讨论中的会议笔记类别](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/) 发布 * 笔记在 48 小时内发布到同一讨论 负责人应积极让工作组成员和参与者参与运营职责，如准备议程、记录会议笔记和主持讨论。 ### 沟通渠道 所有组使用以下渠道： | 渠道 | 目的 | 响应期望 | | ----------------------------------- | ------- | ---- | | Discord `#{name}-wg` 或 `#{name}-ig` | 快速问题、协调 | 尽力而为 | | GitHub 讨论 | 长篇技术讨论 | 每周处理 | 除了 Discord，组还可以在 [GitHub 讨论](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/) 中建立讨论类别。负责人将获得适当的角色来管理和 moderating 讨论。 ### 报告 **工作组** 提供季度更新（1 月、4 月、7 月、10 月底），包括： * 针对交付物的进度 * 受阻事项和升级 * 成员变更 * 即将到来的优先事项 * 资源需求 季度更新作为文档发布在工作组的 [GitHub 讨论](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/) 类别中。它们可选择在核心维护者会议上与核心维护者讨论。 **兴趣组** 没有正式的报告要求，但应保持其章程和成员列表最新。 ### 生命周期 **工作组成立：** * There must be a widely acknowledged concern requiring coordination * PR for creation of WG into `docs/community/working-groups//overview.mdx`, gated by CODEOWNERS requiring approval by Maintainers * PR for charter into `docs/community/working-groups/.mdx`, gated by CODEOWNERS requiring approval from Core Maintainers * Initial member list approved by WG Lead **兴趣组成立：** * 在 [Discord](https://discord.gg/6CSzBmMkjX) 的 `#wg-ig-group-creation` 频道中填写创建模板 * 核心维护者审查提案；兴趣组及其协调人必须由至少两名核心维护者或一名首席维护者担保 * 一旦担保，协调人组织兴趣组并创建章程 **退休：** * **工作组**：工作组负责人或核心维护者提出退休理由；需要核心维护者或首席维护者批准。当工作组在很长一段时间内没有活跃工作或已完成所有计划的交付物时，也会退休。 * **兴趣组**：核心维护者或首席维护者可以退休不再活跃或不再需要的兴趣组。 * 在这两种情况下，文档被归档，渠道被标记为非活动。 ### 章程修订 更改组的章程（工作组或兴趣组）需要： * 由负责人/协调人或核心维护者提出提案 * 由核心维护者批准 ## 章程 每个 MCP 工作组（Working Group）和兴趣小组（Interest Group）都必须维护一份章程文件，记录其特定的使命、范围、领导层、成员和运作方式。上述治理规则自动适用，无需在章程中重复。 请参阅 [小组章程模板](/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/` 下也有文档。 ### 在启动 WG 之前我需要加入 IG 吗？ 不需要。参与 IG 可以帮助验证想法并获得支持，但这不是必需的。如果您心中有明确的交付物并能获得核心维护者的赞助，您可以直接提议成立 WG。 ### 提交 SEP 我需要身在 WG 中吗？ 不需要。任何人都可以提交 SEP。但是，WG 协作可以加强您的提案并帮助其找到赞助者。 ### 如果我的 IG 讨论导致了具体的解决方案怎么办？ 您可以： * 成立一个新的 WG 来构建解决方案 * 如果已有覆盖该领域的 WG，加入现有的 WG * 如果解决方案定义明确，直接提交 SEP ### 一个人可以加入多个 IG/WG 吗？ 可以。根据您的时间允许，参与尽可能多的小组。