Skip to main content

工作组类型

工作组

使命声明

治理工作组负责完善、记录和维护 MCP 的治理流程与社区价值观,为项目发展过程中的治理文档修订提供统一归属。它也是一个咨询声音渠道,以非约束方式向核心维护者反映社区关切,并维护帮助贡献者沿贡献者阶梯成长的协作文化。工作组长期希望成为处理有争议治理决策的常设咨询论坛,并进一步支持 MCP 组织中具有代表性的社区参与。

范围

范围内

  • **治理文档维护:**维护 docs/community/ 下关于治理、贡献者阶梯、SEP 指南、工作组和兴趣组、沟通、反垄断及项目政策的内容。编辑性修订可自主合入;实质性修订需经过工作组共识和核心维护者批准(见下文“权限与决策权”)。由本工作组以外的人员负责的页面,以及由 CODEOWNERS 限制核心维护者修改的工作组和兴趣组章程页,需要与负责人进行更紧密的协作:工作组可以提出修改,但不会自行合入。
  • **记录决策:**定义什么属于项目决策、谁负责批准,以及如何通过会议记录、GitHub Discussions 和 SEP 记录决策。
  • **行为准则维护:**起草、修订和维护行为准则,以及相邻的举报和升级处理文档。内容修订经过“工作组共识 → 核心维护者批准”。
  • **社区价值观:**维护 MCP 声明的社区价值观,包括将正在进行的价值观研讨会成果作为公开内容发布到 docs/community/。
  • **贡献文化与指导:**鼓励将指导作为一种文化(v0.1 不建立正式配对计划),并与 SEP-2148 协作,维护贡献者在阶梯层级间成长的实践。
  • **声音渠道:**以咨询、非约束方式向核心维护者反映贡献者和观察者的社区关切。关切可以在 #governance-wg 或每月工作会议提出;需要核心维护者关注的内容由负责人带到核心维护者与工作组/兴趣组负责人月度会议。
  • **跨组协调:**与其他工作组和兴趣组协调影响它们的治理流程。工作组制定框架;各组的日常运营仍由各组负责。

范围外

  • **规范编写:**协议变更通过SEP 流程和相关规范工作组完成。治理工作组不负责任何规范章节,但可以发起改变治理流程的 SEP。
  • **维护者选择与继任:**首席维护者任命核心维护者,核心维护者批准维护者。工作组可以建议流程改进,但不选择人员。
  • **单个行为准则事件的处理决策:**个别事件举报的接收、调查和裁决不属于本工作组职责。工作组近期目标是从负责事件处理的主体处接收汇总且匿名化的趋势报告,用于政策修订。
  • **按 SDK 划分的治理:**由 SDK 工作组负责。
  • **各工作组/兴趣组内部运营:**每个小组负责自己的会议、优先级和成员协调;治理工作组只制定框架。
  • **非行为准则范围内的维护者争议和人际冲突解决:**明确属于 v0.1 范围外。设计可能的升级路径可以作为未来交付项,但工作组不承担当事方。

相关小组

  • **核心维护者:**重要治理变更、行为准则内容修订和贡献者阶梯结构变更需要核心维护者批准。负责人代表工作组参加核心维护者与工作组/兴趣组负责人月度会议,并以咨询身份在那里反映社区关切。
  • **所有其他工作组和兴趣组:**工作组制定所有小组继承的治理框架(章程模板、决策权和会议要求)。各组运营仍由各组负责;兴趣组将治理问题转交这里。
  • **SDK 工作组:**协调项目级治理与按 SDK 治理之间的边界,后者由 SDK 工作组负责。
  • **未来的行为准则处理主体:**行为准则举报/处理路径正式确定后,负责个别事件的主体会向工作组共享汇总、匿名化趋势报告,用于政策修订。

领导层

由 David Soria Parra(@dsp-ant)发起。

负责人选择与继任

当前负责人为临时任期,自变更日志中记录的章程批准日期起不超过一年。当负责人席位空缺(临时任期结束、负责人卸任,或工作组同意增加席位)时,工作组按以下方式选择未来负责人:
  • 任何工作组成员都可以自荐或由其他成员提名。
  • 候选人必须满足工作组和兴趣组文档中的负责人要求,并且小组领导层必须获得至少两名核心维护者或一名首席维护者的发起支持。
  • 通过工作组共识选择,使用标准决策流程(懒惰共识,必要时进行正式投票),再由核心维护者以章程修订形式批准,因为领导层表格属于本章程。
  • 选择时执行组织多样性不变量(任何单一组织的负责人不得超过 2 名;见“成员资格”)。

权限与决策权

“编辑性与实质性”的界线有意保持狭窄:错别字、澄清、失效链接修复,以及不改变含义的措辞调整属于编辑性修改。改变现有规则的含义、范围或适用性的任何内容都属于实质性修改。 规范仓库中的拉取请求只能由维护者创建。不是维护者的工作组成员应从 fork 或工作组拥有的仓库起草治理文档变更;工作组中的维护者负责打开拉取请求并注明作者。

成员资格

成员资格遵循工作组和兴趣组文档定义的标准工作组模型。成为工作组成员需要:持续参与 3 个月、做出有意义的贡献(对本工作组而言包括治理文档起草、评审或讨论主持)、由现有工作组成员或负责人提名,并且负责人、核心维护者或首席维护者在 7 天内没有反对意见。另有一项结构性规则:任何单一组织的负责人不得超过 2 名,该不变量在整个任期内保持。

运营

每月工作会议是固定时段,不会因为没有议程而取消。如果有已知事项,负责人至少提前 48 小时在 #governance-wg 发布议程。如果连续三次会议既没有出席者也没有议程事项,负责人会向核心维护者提议降低频率或退休该工作组。 会议邀请从项目账户创建,因此任何与会者都可以开始并记录会议。 工作组不设办公时间。公开问答在 #governance-wg 和项目范围的核心维护者办公时间进行。 Discord:#governance-wg GitHub Discussions:Meeting Notes - Governance WG(章程设置期间创建分类)。规范仓库中的讨论仅用于会议记录。 工作组按所有小组都应遵循的标准形式保存会议记录、路线图和会议资料。

交付项与成功指标

当前工作项

成功标准

时间范围从变更日志中的章程批准日期开始。下列日期假定章程于 2026 年 11 月批准。 六个月(截至 2027 年第二季度):
  • 采用决策记录约定,并应用于至少 3 次有记录的会议。
  • 将价值观文档发布到 docs/community/,并在此前的草案阶段收到至少 3 条实质性社区评论。
  • Meeting Notes - Governance WG Discussions 分类上线;每次举行的月度工作会议都发布记录。
  • 整个任期内维持组织多样性不变量:任何单一组织的负责人不超过 2 名。
  • 负责人至少 4 次参加核心维护者与工作组/兴趣组负责人月度会议。
十二个月(截至 2027 年第四季度):
  • 发布第二篇“MCP 社区现状”文章。
  • 入门与指导文化至少促成 3 次引用工作组成果的层级晋升记录。
  • 至少 1 项有争议的治理决策记录工作组向核心维护者提供的咨询意见。
  • 前 6 个月没有因缺少议程而取消会议,或已有记录在案的节奏变更。
延伸目标(成功并不要求,但会跟踪):
  • 从正式成立的行为准则处理主体收到汇总、匿名化的行为准则趋势报告,并用于政策修订。
这些标准对 v0.1 有意保持保守,工作组逐渐成形后可以修订;修订记录在下方变更日志中。

章程更新

本章程是 v0.1 文档,预计会随着工作组逐渐成形而修订。更新遵循适用于所有小组的章程修订流程:由负责人或核心维护者提出,核心维护者批准。在工作组内部,修订提案像其他实质性治理变更一样处理:先取得工作组共识,再获得核心维护者批准。编辑性修复(错别字、失效链接、不改变含义的改写)可以依据上面的编辑性/实质性区分自主合入。所有修订都记录在下方变更日志中。

变更日志