治理工作组章程

社区译文；来源： MCP b491e568

小组类型

工作组

使命陈述

治理工作组负责完善、记录并维护 MCP 的治理流程和社区价值观，为项目发展过程中修订治理文档提供一个统一归口。它也作为咨询性的意见渠道，将社区关切反馈给 Core Maintainer，并维护帮助参与者沿贡献者阶梯成长的贡献文化。随着时间推移，本 WG 希望发展为处理有争议治理决策的常设咨询论坛，并在更长期支持社区以代表性方式参与更广泛的 MCP 组织。

范围

范围内

• 治理文档维护：维护 docs/community/ 下涉及治理、贡献者阶梯、SEP 指南、工作组与兴趣组、沟通、反垄断和项目政策的内容。编辑性修订可自主合入；实质性修订须经过 WG 共识和 Core Maintainer 批准（见下文“权限与决策权”）。对于已指定本 WG 之外 Owner 的页面，以及由 CODEOWNERS 限定仅 Core Maintainer 可批准的 WG 和 IG 章程页面，需要与 Owner 更紧密协作：WG 可提出修改，但不自行合入。
• 决策记录：定义哪些事项构成项目决策、由谁批准，以及如何在会议记录、GitHub Discussions 和 SEP 记录中留档。
• 行为准则维护：起草、修订并维护行为准则正文及相邻的报告和升级文档。内容修订须经过 WG 共识 → Core Maintainer 批准。
• 社区价值观：维护 MCP 明示的社区价值观，包括将正在进行的价值观工作坊成果作为公开产物放入 docs/community/。
• 贡献文化与指导：鼓励形成指导文化（v0.1 不建立正式的结对计划），并与 SEP-2148 协调，维护参与者在贡献者阶梯各层级之间成长的实践。
• 意见渠道：以咨询、非约束方式，将贡献者和观察者的社区关切反馈给 Core Maintainer。关切可在 #governance-wg 或每月工作会议中提出；Lead 将需要 Core Maintainer 关注的事项带到每月一次的 Core Maintainer 与 WG/IG Lead 联席会议。
• 跨领域协调：与其他 WG 和 IG 协调影响这些小组的治理流程。WG 设定框架，各组内部运作仍由各组自行负责。

范围外

• 规范编写：协议变更应遵循 SEP 流程，并由相关的规范产出型工作组负责。治理 WG 从不拥有规范章节，但可以发起改变治理流程的 SEP。
• Maintainer 选任与继任：Lead Maintainer 任命 Core Maintainer；Core Maintainer 批准 Maintainer。WG 可以建议流程改进，但不负责选择人员。
• 行为准则个案处置决定：接收、调查和裁决个别事件报告不属于本 WG 职权。WG 的近期目标是从实际负责事件处理的主体处接收汇总且匿名化的趋势报告，以支持政策修订。
• 各 SDK 的治理：由 SDK 工作组负责。
• 各 WG/IG 的内部运作：各组自行安排会议、确定优先级并协调成员；治理 WG 只设定框架。
• 行为准则之外的 Maintainer 争议和人际冲突解决：明确不属于 v0.1 范围。界定一种可能的升级路径可以作为未来交付物，但本组当前不承担该角色。

相关小组

• Core Maintainer — 重大治理变更、行为准则内容修订和贡献者阶梯结构性变更均须 Core Maintainer 批准。Lead 代表 WG 参加每月一次的 Core Maintainer 与 WG/IG Lead 联席会议，并以咨询身份在那里反馈社区关切。
• 所有其他工作组和兴趣组 — WG 设定所有小组共同遵循的治理框架（章程模板、决策权和会议要求）。各组内部运作仍由各组自行负责。兴趣组将治理问题提交给本组。
• SDK 工作组 — 协调项目级治理与各 SDK 治理之间的边界；各 SDK 的治理归 SDK 工作组负责。
• 未来的行为准则处理机构 — 行为准则报告和处理路径正式建立后，处理个案的机构将向 WG 提供汇总且匿名化的趋势报告，以支持政策修订。

领导

本组由 David Soria Parra（@dsp-ant）发起支持。

Lead 选任与继任

当前 Lead 的临时任期自 Changelog 所记录的章程批准日期起不超过一年。当 Lead 席位空缺——临时任期结束、Lead 辞任，或 WG 同意增加席位——WG 按以下方式选任后续 Lead：

• 任何 WG Member 均可自荐或由另一位 WG Member 提名。
• 候选人必须满足工作组与兴趣组文档中的 Lead 要求，且小组领导层必须继续获得至少两位 Core Maintainer 或一位 Lead Maintainer 的支持。
• 先按标准决策流程由 WG 达成共识（惰性共识，无法达成时转为正式投票），再由 Core Maintainer 将其作为章程修订批准，因为领导表属于本章程的一部分。
• 选任时强制执行组织多样性不变量（任何单一组织最多有 2 位 Lead；见“成员”）。

权限与决策权

“编辑性与实质性”的界线被有意设定得很窄：错别字、澄清、失效链接修复，以及不改变含义的措辞调整属于编辑性修改。任何改变现有规则含义、范围或适用性的修改均属于实质性修改。

只有 Maintainer 可以在规范仓库中创建 pull request。并非 Maintainer 的 WG Member 应从 fork 或 WG 自有仓库起草治理文档修改；WG 内的一位 Maintainer 负责创建 pull request 并注明作者。

成员

成员资格遵循工作组与兴趣组文档定义的标准 WG 模型。成为 WG Member 需要：持续参与超过 3 个月；作出有实质意义的贡献（对本 WG 而言，包括治理文档起草、评审或讨论引导）；由现有 WG Member 或 Lead 提名；并且 Lead、Core Maintainer 或 Lead Maintainer 在 7 天内均未提出异议。另有一条结构性规则：任何单一组织最多有 2 位 Lead。整个任期内均须保持这一不变量。

运作方式

每月工作会议是固定时段，不会因为缺少议程而取消。已知议题时，Lead 至少提前 48 小时在 #governance-wg 发布议程。如果连续三次会议既无人参加也无议题，Lead 将向 Core Maintainer 提议降低频率或退休本组。

会议邀请由项目账户创建，因此任何与会者都可以启动和录制会议。

WG 不设 office hours。开放问答在 #governance-wg 和项目范围的 Core Maintainer office hours 中进行。

Discord：#governance-wg

GitHub Discussions：Meeting Notes - Governance WG（将在章程设置期间创建该分类）。规范仓库中的 Discussions 仅用于会议记录。

WG 按所有小组统一采用的标准结构维护会议记录、路线图和会议信息。

交付物与成功指标

活跃工作项

成功标准

各时间区间从 Changelog 中记录的章程批准日期开始计算。以下日期假设章程于 2026 年 11 月获批。

六个月（截至 2027 年第二季度）：

• 决策记录约定已采用，并应用于至少 3 场有记录的会议。
• 价值观文档已放入 docs/community/；此前草案至少收到 3 条有实质内容的社区评论。
• “Meeting Notes - Governance WG” Discussions 分类已启用；每次已举行的月度工作会议均发布记录。
• 整个任期内保持组织多样性不变量：任何单一组织最多有 2 位 Lead。
• Lead 至少 4 次参加每月一次的 Core Maintainer 与 WG/IG Lead 联席会议。

十二个月（截至 2027 年第四季度）：

• 已发布第二篇“MCP 社区状态”文章。
• 入门与指导文化至少促成 3 次层级晋升提名，且提名中引用 WG 的工作。
• 在至少 1 项有争议的治理决策中记录 WG 向 Core Maintainer 提供的咨询意见。
• 此前 6 个月内没有会议因缺少议程而取消，或已有记录在案的会议频率调整。

延伸目标（不作为“成功”的必要条件，但持续跟踪）：

• 从正式建立的行为准则处理机构收到汇总且匿名化的行为准则趋势报告，并据此修订政策。

这些标准针对 v0.1 有意保持保守，并可随着小组逐步成形而修订；修订记录在下方 Changelog 中。

章程更新

本章程是 v0.1 文档，预计会随着小组逐步成形而修订。更新遵循为所有小组定义的章程修订流程：由 Lead 或 Core Maintainer 提案，并由 Core Maintainer 批准。在 WG 内部，修订提案按其他实质性治理变更处理——先达成 WG 共识，再由 Core Maintainer 批准。编辑性修复（错别字、失效链接和不改变含义的措辞调整）可按上述编辑性/实质性区分自主合入。所有修订均记录在下方 Changelog 中。

变更日志