SEP-2148：MCP 贡献者阶梯

社区译文；来源： MCP 29affa6b

摘要

本 SEP 为 Model Context Protocol 项目建立正式的贡献者阶梯，定义从首次贡献者到 Core Maintainer 的明确角色、职责和晋升标准。该阶梯为社区成员提供透明的发展路径，帮助他们了解如何逐步扩大对项目的参与和影响。

本 SEP 与 SEP-2149：MCP 工作组治理与章程模板配套，后者定义 Working Group 和 Interest Group 的运作方式。两份 SEP 相互衔接：WG/IG 领导者必须具有 Member 身份；参与小组也是获得阶梯晋升认可的一条路径。

动机

随着 MCP 的采用不断增长，项目需要一个清晰的框架来解决以下问题：

1. 贡献者发展：社区成员不了解如何扩大自己在 MCP 项目中的参与和影响。明确的阶梯展示从首次贡献到项目领导的路径。

2. 建立信任：合并权限及其他高权限职责，应通过长期展现出的投入和良好判断力获得。分阶段的体系能帮助贡献者做好承担更大项目责任的准备，并赢得现有维护者和更广泛社区的信任。

3. 组织多样性：随着多个组织参与 MCP，项目需要机制来防止贡献者群体被单一组织控制，同时欢迎 Anthropic 以外的参与者。

4. 可扩展性：Core Maintainer 的带宽有限。通过清晰界定范围，将权限委派给 Maintainer 以及 Working/Interest Group Leads，可以让项目扩展。

5. 认可：贡献者为 MCP 投入了大量精力。通过明确角色给予正式认可，既能肯定他们的贡献，也能鼓励持续参与。

没有贡献者阶梯，晋升决定就容易变得临时、前后不一且对社区不透明。

规范

指导原则

贡献者阶梯遵循以下原则：

• 以信任为基础：晋升依据是符合项目目标的、有意义的贡献、良好判断力和持续参与，而不只是资历
• 多种成长路径：代码、规范工作、文档和社区建设均可带来晋升
• 透明：晋升标准明确并得到一致执行
• 与 MCP 目标一致：个人贡献者必须展现出推动和演进 MCP 项目组件的承诺，而非只服务于雇主利益

角色定义

表中时间线是最低贡献期限，不是晋升保证。设置这些期限是为了防止权限过快升级，并确保贡献者展现出足够高水平的投入。晋升由相关负责人酌情决定，实际所需时间可能更长；唯一的保证是晋升不会早于所列时间。例外情况必须由 Core Maintainer 明确批准并记录理由。

Contributor

任何以任何形式为 MCP 作出贡献的人都是贡献者，包括：

• 提交 issue 或开启讨论
• 提交 pull request
• 参与工作组讨论
• 改进文档
• 帮助其他社区成员

没有正式要求，我们欢迎所有贡献。

如何开始：

• 阅读贡献指南
• 加入社区频道（Discord、GitHub Discussions）
• 查找标记为 good-first-issue 或 help-wanted 的 issue
• 参加工作组会议

Member

Member 是已建立稳定参与、并展现出持续支持 MCP 成功与发展的贡献者。

要求：

• 多次为 MCP 作出贡献（代码、文档和/或社区工作）
• 至少有一个已合并的 PR 或已被接受的贡献
• 持续参与 MCP 社区，而非只作一次性贡献
• 已在 GitHub 启用双因素认证
• 现有 Member 在 7 天内没有提出异议

赞助：

• 由来自不同组织的两位现有 Member 或 Maintainer 赞助
• 或由一位 Core Maintainer 或 Lead Maintainer 赞助

**最低时间线：**积极参与 2-3 个月

职责：

• 继续本着诚信原则作出贡献
• 及时响应分配给自己的 issue 和 PR
• 遵守社区指南和行为准则
• 条件允许时帮助新贡献者融入

权限：

• 获得 GitHub 组织成员身份和问题分诊权
• 可被指派处理 issue 和 PR
• 可在 PR 中使用 /lgtm 等快捷审批或评审命令
• 列入社区成员名册
• 可在受限仓库中创建 PR
• 符合担任 Working Group Lead 或 Interest Group Facilitator 的资格

**非活跃：**连续 3 个月没有贡献的 Member 可转为 emeritus（荣誉）状态。重新参与时可采用简化的重新熟悉流程。

Maintainer

Maintainer 是受信任的负责人，对特定领域承担运营责任。

要求：

• 担任 Member 至少 6 个月，并持续作出高质量贡献
• 展现出在工作组或重要计划中的领导力
• 能够把 MCP 的利益置于个人雇主或所属组织的利益之上
• 深入理解 MCP 的愿景、路线图和设计原则
• 了解其负责领域对现实世界中的 AI 集成和模型交互模式有何影响
• 完成安全与治理入门培训

赞助与审批：

• 由现有 Maintainer 或 Core Maintainer 赞助
• 由 Core Maintainer 批准

职责：

• 对负责领域的运营健康状况负责（测试稳定性、文档时效性）
• 负责相应范围内的发布流程和里程碑规划
• 及时评审升级上来的决定
• 积极参与治理讨论
• 指导 Member 并培养未来的 Maintainer
• 适当时在外部场合代表 MCP
• 参与所在领域的生态和利益相关方，了解实际使用情况并代表社区需求
• 确保提交给 Core Maintainer 的提案经过完善、审慎考虑，并涵盖整个生态的影响
• 积极参与沟通渠道中的讨论（GitHub issue、Discord）

权限：

• 对所负责领域拥有合并权限
• 可赞助新的 Maintainer
• 参与路线图和优先级讨论
• 列入 MAINTAINERS.md
• 参与发布

所有路径都可能通向 Maintainer，具体负责范围将与贡献类型相匹配。

**非活跃：**连续 6 个月没有贡献的 Maintainer，经 Core Maintainer 审查后可转为 emeritus 状态。转为 emeritus 后将撤销合并权限。重新参与需要重新完成安全与治理入门培训。

Core Maintainer

Core Maintainer 对 MCP 技术方向拥有最终决策权，是社区给予的最高级别信任。

注意：Core Maintainer 角色有意保持精简，以便项目扩展时仍维持一致的技术愿景。Core Maintainer 带宽问题通过更明确地向 Maintainer、Working Group Lead 和 Interest Group Facilitator 委派工作来解决，而不是增加 Core Maintainer 人数。

要求：

• 作为 Maintainer 或类似角色持续贡献至少 6 个月
• 在复杂的全项目决策中展现出良好判断力
• 获得跨组织的信任和尊重
• 深切投入 MCP 的长期成功

任命：

• 由多数 Core Maintainer 提名，并经 Lead Maintainer 批准
• 或由 Lead Maintainer 直接任命

评估候选人时，Core Maintainer 应考虑当前成员构成是否充分代表 MCP 生态的广度，包括在生产领域部署 MCP 的企业采用者。

职责：

• 对有争议或跨领域问题作出最终技术决策
• 维护项目愿景和设计原则
• 作出治理与政策决策
• 对外代表 MCP
• 规划继任并维护社区健康
• 确保协议演进保持克制和可持续
• 参与 Core Maintainer 会议和聚会

权限：

• 对破坏性变更和重大规范修订作最终批准
• 对 SEP（Specification Enhancement Proposals，规范增强提案）拥有投票权
• 批准 Maintainer
• 拥有治理投票权，并应参与治理
• 对所有 MCP GitHub 仓库拥有管理权限
• 作为 Core Maintainer 列入 MAINTAINERS.md

**非活跃：**连续 6 个月未参与治理或技术决策的 Core Maintainer，经 Lead Maintainer 审查后可转为 emeritus 状态。鉴于该角色所承载的信任和影响力，Core Maintainer 应主动说明自己可投入时间的变化。

Lead Maintainer

Lead Maintainer 对 MCP 的方向和治理拥有最高权限。该终身任命仅保留给项目创始人。本角色没有明确的晋升路径；仅在必要时通过继任接任（参见继任）。

职责：

• 承担 Core Maintainer 的全部职责
• 任命和罢免 Core Maintainer
• 对有争议的治理决定拥有最终权限
• 制定全项目战略方向

权限：

• 在 Core Maintainer 需要多人批准的事项中可单独采取行动
• 对任何决定拥有否决权
• 任命继任者

继任

如果 Lead Maintainer 因任何原因离任，继任流程将在其书面通知时启动；若其无法提供通知，则由剩余 Lead Maintainer 或 Core Maintainer 判定其无法继续履职时启动。

如果仍有一位或多位 Lead Maintainer 留任，他们应任命继任者（若有多人则以多数票决定）；继任者获任命前，留任的 Lead Maintainer 将继续履行治理职责。

如果没有 Lead Maintainer 留任，Core Maintainer 应在 30 天内以多数票任命继任者；新 Lead Maintainer 任命之前，项目由 Core Maintainer 以三分之二多数票治理。

晋升流程

自荐与他人认可

贡献者可以：

1. 在认为自己符合要求时自荐
2. 由观察过其贡献的赞助人提名

两种方式同样有效。鼓励并优先采用自荐，因为这体现了主动性，也说明候选人了解自己的贡献范围。

流程步骤

1. 提名：候选人或赞助人使用提名模板创建 issue，附上能证明符合要求的贡献链接和赞助人确认
2. 社区评议：社区意见征集期为 7 天
3. 决定：审批负责人审阅并作出决定
4. 入职培训：新任角色持有人获得相应访问权限并接受入门培训

鼓励自荐，但候选人仍须获得规定的赞助。赞助人应在提名 issue 中确认支持。

决策与升级

默认采用委派

MCP 按照委派原则运作：决定应由适当层级中最低的一级作出。这样既能让项目快速推进，也能为跨领域问题保留 Core Maintainer 的带宽。

• Maintainer、WG Lead 和 IG Facilitator 在各自范围内处理日常决定
• Core Maintainer 在问题升级、涉及跨领域事项或流程要求时介入（例如规范变更、批准 Maintainer）
• Lead Maintainer 仅在治理决定有争议或 Core Maintainer 无法达成共识时介入

如有疑问，应在自己的权限层级内作出决定并记录。只有遇到阻塞、决定会影响整个项目，或流程明确要求时才升级。

Working Group 和 Interest Group 争议的详细升级程序，包括指定一位与争议双方没有共同组织关系的 Core Maintainer 来解决问题，见 SEP-2149 §1.5。

升级矩阵

升级流程：

1. 记录决定、已考虑的选项和分歧点
2. 向升级处理负责人说明情况并明确提出需要其处理的事项
3. 升级处理负责人可以：(a) 提供有约束力的指导；(b) 要求补充信息；或 (c) 必要时继续升级

贡献路径

MCP 重视多样化贡献。以下是受到认可的晋升路径：

代码贡献

• SDK 开发（TypeScript、Python 等）
• 测试基础设施
• 工具和开发者体验

规范工作

• 起草或完善规范文本
• SEP 的撰写或共同撰写
• 参与协议设计
• 兼容性分析

文档

• 用户指南和教程
• API 文档
• 架构文档
• 维护内容的时效性

社区建设

• 帮助新贡献者融入
• 主持工作组
• 社区支持（Discord、GitHub discussions）
• 组织活动或代表社区出席活动

质量与安全

• Bug 分诊与复现
• 安全评审与分析
• 改进测试覆盖率
• 发布验证

Working Group 和 Interest Group 领导

Working Group (WG) Lead 和 Interest Group (IG) Facilitator 是一种特殊的社区领导角色，不要求具有 Maintainer 身份。WG/IG 领导侧重于引导和协调，而非合并权限。WG 和 IG 的完整治理规则，包括参与层级、决策流程、会议要求和生命周期，见 SEP-2149：MCP 工作组治理与章程模板。

要求：

• 至少具有 Member 身份
• 持续参与 WG/IG 的职责范围并有所证明
• 具备良好的引导和沟通能力
• 能公平代表多种观点
• 小组及其领导者须由至少两位 Core Maintainer 或一位 Lead Maintainer 赞助

与贡献者阶梯的关系：

• 担任 WG Lead 和 IG Facilitator 的经历有助于晋升为 Maintainer
• 不具备 Maintainer 身份的 WG Lead 和 IG Facilitator 应与 Maintainer 协作作出合并决定
• WG Lead 和 IG Facilitator 对小组运作有权限，但没有规范审批权
• WG Lead 和 Maintainer 可以赞助 SEP
• WG Lead 可以分诊其职责范围内的 SEP，包括在有记录说明理由的情况下关闭不符合 WG 路线图的 SEP（作者可以向 Core Maintainer 申诉）

Community Moderator

Community Moderator 是受信任的社区成员，负责维护 MCP 社区的健康、安全和友好氛围。这是专注于社区管理和执行行为准则的专门角色，不以技术贡献为重点。

要求：

• 至少具有 Member 身份
• 在社区互动中展现出良好判断力和沉着态度
• 了解 MCP 行为准则和社区指南
• 能够谨慎、公平地处理敏感情况

赞助：

• 由 Core Maintainer 或 Lead Maintainer 赞助

职责：

• 监督社区频道（Discord、GitHub Discussions 等）是否遵守行为准则
• 处理行为准则事件报告，包括初步分诊和响应
• 将严重或复杂事件升级给 Core Maintainer
• 帮助维护对所有社区成员友好且包容的环境
• 与其他 moderator 协调，确保执行一致
• 记录管理措施并对事件细节保密
• 如涉及本人，应回避该事件；此类事件由 Core Maintainer 直接处理

权限：

• 在社区平台（Discord、GitHub Discussions）上拥有管理权限
• 可访问管理工具和私有管理频道
• 对违反行为准则的用户有权警告、禁言或临时封禁
• 列入社区 moderator 名册

与贡献者阶梯的关系：

• Community Moderator 是并行路径，不是技术晋升的前置条件
• moderator 经验对晋升到任何角色都有价值，尤其是需要社区判断力的角色
• Moderator 可同时担任其他角色（Member、Maintainer 等）

**免职：**未能遵守管理标准或违反行为准则时，Core Maintainer 可免去 Community Moderator 职务。Moderator 也可以随时自愿卸任。

认可与可见度

社区通过以下方式认可贡献者：

• 贡献者名单，例如 MAINTAINERS.md
• GitHub teams，用于授予适当访问权限
• 在发布说明中公开致谢
• 在社区活动中提供演讲机会
• 在社区平台上设置徽章（如已实现）

卸任与 emeritus 状态

贡献者可以因任何原因卸任。这是正常且健康的做法。

流程：

1. 通知相关负责人（视情况为 WG Lead、IG Facilitator、Maintainer 或 Core Maintainer）
2. 协助交接正在进行的工作
3. 转为 emeritus 状态

Emeritus：

• 肯定其过去作出的贡献
• 可通过简化的重新入职培训恢复活跃身份
• 不承担持续职责，也不再拥有权限

**非自愿免职：**如违反行为准则或长期不参与，可按适当的审查流程撤销角色。

理由

为什么需要正式阶梯？

非正式晋升会导致标准不一且过程不透明。正式阶梯可以：

• 为所有相关方设定明确预期
• 为讨论晋升提供共同词汇
• 让晋升决定更具问责性
• 允许自荐，从而减少把关造成的障碍

为什么设置最低时间线？

时间线是下限，不是目标。设置这些期限是为了建立安全和信任：

• 信任通过长期展现出的行为建立
• 权限过快升级会增加安全风险
• 深入理解项目需要持续参与
• 行为模式只有经过较长时间才会显现

达到最低时间线并不意味着有权晋升；这只代表具备接受评估的资格。低于最低期限的例外必须由 Core Maintainer 明确批准并记录理由。

为什么要求来自两个组织的赞助？

要求赞助人来自不同组织，可以：

• 防止贡献者群体被单一组织控制
• 确保贡献者获得雇主以外人士的认可
• 在晋升决定中维持多样观点

模型启发

本阶梯以 Kubernetes 社区成员结构为模型，并根据 MCP 的需求和发展阶段作了调整。

向后兼容性

本 SEP 建立新流程，不修改现有结构。当前贡献者保留其已有访问权限和身份。

安全影响

本 SEP 通过以下措施直接处理安全问题：

• 按时间要求逐级提升权限
• 要求 Member 启用双因素认证
• 要求多组织赞助以防止组织控制
• 要求 Maintainer 完成安全入门培训

参考实现

本 SEP 获批后，将通过以下方式实现：

1. 将贡献者阶梯添加到 docs/community/contributor-ladder.mdx
2. 在 .github/ISSUE_TEMPLATE/ 中创建提名 issue 模板（清单模板见附录）
3. 更新 MAINTAINERS.md 格式以体现角色区别

附录：清单模板

Member 提名清单

**Nominee:** [GitHub handle]
**Sponsors:** [GitHub handles]
  - **Organizations represented:** [Must be 2+ different orgs among sponsors]

**Contributions:**
- [ ] Link to merged PR(s)
- [ ] Link to issues filed/triaged
- [ ] Link to discussions participated in
- [ ] Duration of participation: [X months]

**Sponsor Attestations:**
Sponsors confirm
- [ ] Sponsors confirm nominee demonstrates community values
- [ ] Sponsors confirm nominee demonstrates sustained engagement

Maintainer 提名清单

**Nominee:** [GitHub handle]
**Scope:** [Specific area]
**Sponsor:** [GitHub handle, must be Maintainer or Core Maintainer]

**Requirements:**
- [ ] Member for 6+ months with sustained, high-quality contributions
- [ ] Links to demonstrated leadership in WG, IG, or significant initiatives
- [ ] Evidence of representing MCP's interests above employer/organization interests
- [ ] Deep understanding of MCP vision, roadmap, and design principles
- [ ] Security and governance onboarding completed (or scheduled)

**Core Maintainer Approval:**
- [ ] Approved by Core Maintainers

Community Moderator 提名清单

**Nominee:** [GitHub handle]
**Sponsor:** [GitHub handle, must be Core Maintainer or Lead Maintainer]

**Requirements:**
- [ ] Member status
- [ ] Links to demonstrated good judgment and composure in community interactions
- [ ] Confirmed understanding of the MCP Code of Conduct and community guidelines

**Sponsor Attestation:**
- [ ] Sponsor confirms nominee can handle sensitive situations with discretion and fairness