SEP-2148：MCP 贡献者阶梯

• 状态（Status）: Final
• 类型（Type）: Process
• 创建（Created）: 2026-01-15
• 作者（Author(s)）: David Soria Parra (@dsp-ant), Sarah Novotny (@sarahnovotny)
• 担保人（Sponsor）: David Soria Parra (@dsp-ant)
• PR: https://github.com/modelcontextprotocol/specification/pull/2148

​

摘要

​

动机

1. 贡献者发展：社区成员对如何在 MCP 项目内增长其参与和影响力缺乏可见性。一套既定阶梯展示了从首次贡献到项目领导的路径。
2. 信任构建：合并权限和其他高权限职责，是随时间通过已展现的承诺和良好判断力赢得的。分级体系确保贡献者在承担对项目更大的所有权之前，被准备好取得成功，并被既有维护者和更广泛社区所信任。
3. 组织多样性：在有多个组织为 MCP 做贡献的情况下，项目需要机制来防止组织俘获，同时欢迎来自 Anthropic 之外的参与。
4. 可扩展性：核心维护者的带宽有限。通过清晰的范围定义将权限委派给维护者和工作组/兴趣组 Lead，使项目能够扩展。
5. 认可：贡献者在 MCP 上投入了大量精力。通过既定角色的正式认可承认他们的贡献，并鼓励持续的投入。

​

规范

​

指导原则

• 赢得的信任：晋升基于已展现的、与项目目标一致的有意义贡献、良好判断力和持续投入，而非仅凭资历
• 多条成长路径：代码、规范工作、文档和社区建设都能通向晋升
• 透明：晋升标准是显式的，且被一致地应用
• 与 MCP 目标一致：个人贡献者必须展现出推进和演进 MCP 项目组件、超越自身雇主利益的承诺

​

角色定义

​

贡献者

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

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

​

成员

• 对 MCP 的多次贡献（代码、文档，及/或社区）
• 至少一个已合并的 PR 或已被接受的贡献
• 与 MCP 社区的持续互动，而不仅是一次性的贡献
• 在 GitHub 上启用双因素认证
• 7 天内现有成员无异议

• 由来自不同组织的两位现有成员或维护者担保
• 或由一位核心维护者或首席维护者担保

• 继续本着诚意贡献
• 对被指派的 issue 和 PR 保持响应
• 遵循社区指南和行为准则
• 在可能时帮助新贡献者上手

• 具有分诊权限的 GitHub 组织成员身份
• 可被指派到 issue 和 PR
• 可在 PR 上使用快捷批准或评审命令，例如 /lgtm
• 列于社区成员名录
• 可在受限仓库中创建 PR
• 有资格担任工作组 Lead 或兴趣组主持人角色

​

维护者

• 作为成员至少 6 个月，有持续、高质量的贡献
• 在工作组或重大倡议中展现出领导力
• 已展现出将 MCP 的利益置于个别雇主或组织利益之上的能力
• 对 MCP 愿景、路线图和设计原则有深刻理解
• 理解其领域如何影响现实世界的 AI 集成和模型交互模式
• 完成安全和治理上手培训

• 由一位现有维护者或核心维护者担保
• 经核心维护者批准

• 领域健康的运营所有权（测试稳定性、文档时效性）
• 负责其各自范围的发布流程和里程碑规划
• 及时评审上报的决策
• 积极参与治理讨论
• 指导成员并培养未来的维护者
• 在适当时于外部场合代表 MCP
• 与该领域的生态和利益相关方互动，理解现实世界的使用，并代表社区需求
• 确保到达核心维护者的提案经过打磨、深思熟虑，并考虑到生态全局的影响
• 积极参与沟通渠道（GitHub issue、Discord）上的讨论

• 所拥有领域的合并权限
• 可担保新的维护者
• 参与路线图和优先级讨论
• 列于 MAINTAINERS.md
• 参与发布

​

核心维护者

• 作为维护者或类似角色至少 6 个月的持续贡献
• 在复杂的、项目全局的决策上展现出判断力
• 跨组织边界的信任和尊重
• 对 MCP 长期成功的深切承诺

• 由多数核心维护者提名，经首席维护者批准
• 或由首席维护者直接任命

• 对有争议的或跨领域的问题的最终技术决定权
• 对项目愿景和设计原则的管理
• 治理和政策决策
• MCP 的对外代表
• 继任规划和社区健康
• 确保协议演进中的克制和可持续性
• 参加核心维护者会议和核心维护者聚会

• 对破坏性变更和重大规范修订的最终批准
• 对 SEP（规范增强提案）的投票权
• 对维护者的批准
• 治理投票权 / 参与治理的预期
• 对所有 MCP GitHub 仓库的管理员权限
• 在 MAINTAINERS.md 中列为核心维护者

​

首席维护者

• 全部核心维护者职责
• 任命和移除核心维护者
• 对有争议治理决策的最终权威
• 项目全局的战略方向

• 在核心维护者需要多方批准之处可以单独行动
• 对任何决策的否决权
• 任命继任者

​

继任

​

晋升流程

​

自我提名 vs. 认可

1. 在认为自己符合要求时自我提名
2. 由观察到其贡献的担保人提名

​

流程步骤

1. 提名：被提名人或担保人使用提名模板开一个 issue，包含展现要求的贡献链接和担保人确认
2. 社区评审：7 天的社区意见期
3. 决定：批准权威者评审并决定
4. 上手：新的角色持有者获得相应的访问权限和上手引导

​

决策与上报

​

委派为默认

• 维护者、WG Lead 和 IG 主持人处理范围内的日常决策
• 核心维护者在上报、跨领域问题，或流程要求时（规范变更、维护者批准）介入
• 首席维护者仅在有争议的治理决策，或核心维护者无法达成共识时介入

​

上报矩阵

1. 记录该决策、所考虑过的选项和分歧点
2. 附一个清晰的诉求呈交给上报权威者
3. 上报权威者或者：(a) 提供有约束力的指导，(b) 请求更多信息，或 (c) 在需要时进一步上报

​

贡献路径

​

代码贡献

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

​

规范工作

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

​

文档

• 用户指南和教程
• API 文档
• 架构文档
• 保持内容时效性

​

社区建设

• 引导新贡献者上手
• 工作组主持
• 社区支持（Discord、GitHub discussions）
• 活动组织或代表

​

质量与安全

• 缺陷分诊和复现
• 安全评审和分析
• 测试覆盖改进
• 发布验证

​

工作组和兴趣组领导

• 至少成员身份
• 已展现出对该 WG/IG 范围的持续投入
• 良好的主持和沟通技巧
• 有能力公平地代表多种视角
• 群组及其领导层由至少两位核心维护者或一位首席维护者担保

• WG Lead 和 IG 主持人经验对晋升为维护者很有价值
• 没有维护者身份的 WG Lead 和 IG 主持人就合并决策与维护者协作
• WG Lead 和 IG 主持人对群组运营有权限，但对规范批准没有
• WG Lead 和维护者可以担保 SEP
• WG Lead 可以分诊其范围领域内的 SEP，包括关闭不契合 WG 路线图的 SEP（附成文理由；作者可向核心维护者申诉）

​

社区版主

• 至少成员身份
• 在社区互动中展现出良好的判断力和沉稳
• 理解 MCP 行为准则和社区指南
• 有能力以谨慎和公平处理敏感情况

• 由一位核心维护者或首席维护者担保

• 监控社区渠道（Discord、GitHub Discussions 等）对行为准则的遵守
• 处理行为准则事件报告，包括初步分诊和响应
• 将严重或复杂的事件上报给核心维护者
• 帮助为所有社区成员维护友好和包容的环境
• 与其他版主协调以确保一致的执行
• 记录审核行动并对事件细节保密
• 在任何涉及其本人的事件中回避；此类事件直接由核心维护者处理

• 社区平台（Discord、GitHub Discussions）上的审核权限
• 访问审核工具和私密审核频道
• 对违反行为准则者发出警告、禁言或临时封禁用户的权力
• 列于社区版主名录

• 社区版主是一条平行轨道，而非技术晋升的前提
• 版主经验对晋升至任何角色都受重视，尤其在社区判断力重要之处
• 版主可以同时持有其他角色（成员、维护者等）

​

认可与曝光

• 贡献者列表，例如 MAINTAINERS.md
• 用于相应访问权限的 GitHub 团队
• 发布说明中的公开致谢
• 社区活动中的演讲机会
• 社区平台上的徽章（如已实现）

​

卸任与荣誉退任状态

1. 通知相关领导（视情况为 WG Lead、IG 主持人、维护者或核心维护者）
2. 帮助交接任何进行中的工作
3. 转为荣誉退任状态

• 因过去的贡献受到认可
• 可通过简略的重新上手回到活跃状态
• 没有持续的职责或权限

​

理由

​

为何要正式阶梯？

• 为各方设定清晰的预期
• 为讨论晋升提供共同的词汇
• 在晋升决策中创造问责
• 支持自我提名，减少把关

​

为何要最短时间线？

• 信任是随时间通过已展现的行为构建的
• 安全风险随权限的快速升级而增加
• 对项目的深刻理解需要持续投入
• 行为模式只在较长时期后才变得可见

​

为何要两个组织的担保？

• 防止贡献者基础被组织俘获
• 确保贡献者获得超越其雇主的认可
• 在晋升决策中保持多样化视角

​

模型灵感

​

向后兼容性

​

安全影响

• 带时间线要求的分级权限升级
• 对成员的双因素认证要求
• 多组织担保以防止俘获
• 对维护者的安全上手要求

​

参考实现

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

​

附录：清单模板

​

成员提名清单

**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

​

维护者提名清单

**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

​

社区版主提名清单

**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