最终版流程
| 字段 | 值 |
|---|---|
| SEP | 2148 |
| 标题 | MCP 贡献者阶梯 |
| 状态 | 最终版 |
| 类型 | 流程 |
| 创建日期 | 2026-01-15 |
| 作者 | David Soria Parra (@dsp-ant), Sarah Novotny (@sarahnovotny) |
| 推荐人 | David Soria Parra (@dsp-ant) |
| PR | #2148 |
摘要
本 SEP 为 Model Context Protocol 项目建立了一个正式的贡献者阶梯，定义了从首次贡献者到核心维护者的清晰角色、责任和晋升标准。该阶梯为社区成员提供了透明的路径，使他们能够了解如何在项目中成长其参与度和影响力。 本 SEP 是 SEP-2149: MCP 工作组治理与章程模板 的配套文件，后者定义了工作组和兴趣组的运作方式。这两个 SEP 相互交叉：工作组/兴趣组领导需要在此阶梯上具有成员状态，而小组参与是阶梯晋升的认可路径。动机
随着 MCP 采用的增长，项目需要一个清晰的框架来：- 贡献者发展：社区成员缺乏关于如何在 MCP 项目中成长其参与度和影响力的可见性。定义的阶梯展示了从首次贡献到项目领导的路径。
- 建立信任：合并权限和其他高权限责任是通过随着时间的推移展现出的承诺和良好的判断力而赢得的。分级系统确保贡献者为成功做好准备，并在承担更大的项目所有权之前获得现有维护者和更广泛社区的信任。
- 组织多样性：随着多个组织为 MCP 做出贡献，项目需要机制来防止组织俘获，同时欢迎来自 Anthropic 以外的参与。
- 可扩展性：核心维护者的精力有限。通过明确的范围定义将权力下放给维护者和工作组/兴趣组负责人，使项目能够扩展。
- 认可：贡献者在 MCP 上投入了大量精力。通过定义的角色进行正式认可，承认他们的贡献并鼓励持续的参与。
规范
指导原则
贡献者阶梯在这些原则下运作：- 赢得信任：晋升基于与项目目标一致的有意义的贡献、良好的判断力和持续的参与，而不仅仅是资历
- 多种成长路径：代码、规范工作、文档和社区建设都能导致晋升
- 透明度：晋升标准是明确的且一致应用的
- 与 MCP 目标一致：个人贡献者必须表现出承诺，以推进和发展 MCP 项目组件，超越雇主的利益
角色定义
列出的时间线是最短贡献期，不是晋升保证。它们的存在是为了保护项目免受快速权限升级，并确保展现出高标准的承诺。实际晋升是酌情的，实践中可能需要更长时间；唯一的保证是晋升不会比记录的时间尺度更短发生。例外情况需要核心维护者明确批准并记录理由。
贡献者
任何以任何形式为 MCP 做出贡献的人都是贡献者。这包括：- 开启问题或讨论
- 提交拉取请求
- 参与工作组讨论
- 改进文档
- 帮助其他社区成员
- 查阅 贡献指南
- 加入社区渠道（Discord、GitHub 讨论）
- 寻找标记为
good-first-issue或help-wanted的问题 - 参加工作组会议
成员
成员是既定的贡献者，他们展示了对 MCP 成功和成长的持续承诺。 要求：- 对 MCP 有多次贡献（代码、文档和/或社区）
- 至少一个合并的 PR 或接受的贡献
- 与 MCP 社区持续互动，不仅仅是一次性贡献
- 在 GitHub 上启用了双因素认证
- 现有成员在 7 天内无异议
- 由来自不同组织的两名现有成员或维护者推荐
- 或由一名核心维护者或首席维护者推荐
- 继续诚意贡献
- 对分配的问题和 PR 做出响应
- 遵循社区指南和行为准则
- 在可能的情况下帮助引导新贡献者
- 具有分类权限的 GitHub 组织成员资格
- 可以被分配到问题和 PR
- 可以在 PR 上使用快捷批准或审查命令，例如
/lgtm - 列入社区成员名单
- 可以在受限仓库中创建 PR
- 有资格担任工作组负责人或兴趣组协调员角色
维护者
维护者是值得信赖的守护者，对特定领域承担运营责任。 要求：- 成为成员至少 6 个月，具有持续、高质量的贡献
- 在工作组或重大倡议中展现出领导力
- 展现出代表 MCP 利益高于个人或组织利益的能力
- 深刻理解 MCP 愿景、路线图和设计原则
- 理解其领域如何影响现实世界的 AI 集成和模型交互模式
- 完成安全和治理引导
- 由现有维护者或核心维护者推荐
- 由核心维护者批准
- 领域健康的运营所有权（测试稳定性、文档时效性）
- 负责各自范围的发布流程和里程碑规划
- 提供升级决策的及时审查
- 积极参与治理讨论
- 指导成员并培养未来的维护者
- 在适当时在外部环境中代表 MCP
- 参与领域生态系统和利益相关者，了解现实世界的使用情况，并代表社区需求
- 确保到达核心维护者的提案是经过完善、深思熟虑的，并考虑到生态系统范围的影响
- 积极参与沟通渠道上的讨论（GitHub 问题、Discord）
- 拥有领域的合并权限
- 可以推荐新维护者
- 参与路线图和优先级讨论
- 列入
MAINTAINERS.md - 参与发布
核心维护者
核心维护者拥有对 MCP 技术方向的最终决策权。这是社区中最高级别的信任。 注意：核心维护者角色故意受限，以确保在项目扩展时技术愿景的连贯性。核心维护者的精力问题通过更清晰地向维护者、工作组负责人和兴趣组协调员下放权力来解决，而不是扩大核心维护者的数量。 要求：- 作为维护者或类似角色持续贡献至少 6 个月
- 在复杂的、项目范围的决策上展现出判断力
- 跨越组织边界获得信任和尊重
- 对 MCP 的长期成功有深刻承诺
- 由多数核心维护者提名，由首席维护者批准
- 或由首席维护者直接任命
- 对有争议或跨领域问题的最终技术决策权
- 项目愿景和设计原则的守护
- 治理和政策决策
- MCP 的外部代表
- 继任规划和社区健康
- 确保协议演进中的克制和可持续性
- 参与核心维护者会议和核心维护者聚会
- 对破坏性变更和主要规范修订的最终批准
- 对 SEP（规范增强提案）的投票权
- 维护者的批准
- 治理投票权/期望参与治理
- 所有 MCP GitHub 仓库的管理权限
- 在
MAINTAINERS.md中列为核心维护者
首席维护者
首席维护者拥有对 MCP 方向和治理的最终权威。这是保留给项目创始人的终身任命。没有定义通往此角色的晋升路径；只有在必要时通过继任承担（见 继任）。 职责：- 所有核心维护者职责
- 核心维护者的任命和移除
- 有争议的治理决策的最终权威
- 项目范围的战略方向
- 在核心维护者需要多次批准的情况下可以单独行动
- 对任何决策的否决权
- 任命继任者
继任
如果首席维护者因任何原因离开其角色，继任过程在其书面通知时开始，或者如果无法提供通知，则在剩余的首席维护者或核心维护者确定首席维护者无法继续服务时开始。 如果仍有一名或多名首席维护者，他们应任命继任者（如果有多人则通过多数投票），剩余的首席维护者将继续治理直到任命继任者。 如果没有首席维护者剩余，核心维护者应在 30 天内通过多数投票任命继任者，项目在任命新首席维护者之前由核心维护者的三分之二投票运作。晋升流程
自我提名与推荐
贡献者可以：- 自我提名，当他们认为自己满足要求时
- 被推荐，由观察到其贡献的推荐人
流程步骤
- 提名：被提名者或推荐人使用提名模板开启一个问题，包括展示要求的贡献链接和推荐人确认
- 社区审查：7 天的社区输入期
- 决策：批准机构审查并决定
- 引导：新角色持有者获得适当的访问和引导
| 晋升至 | 批准者 |
|---|---|
| 成员 | 2 名来自不同组织的现有成员+，或 1 名核心/首席维护者 |
| 维护者 | 1 名维护者或核心维护者推荐人 + 核心维护者批准 |
| 核心维护者 | 首席维护者 |
| 社区管理员 | 1 名核心维护者或首席维护者 |
决策与升级
默认委托
MCP 基于委托原则运作：决策应在最低的适当级别做出。这使得项目能够快速移动，同时保留核心维护者的精力用于跨领域关注点。- 维护者、工作组负责人和兴趣组协调员 处理范围内的日常决策
- 核心维护者 在升级、跨领域问题或需要时干预（规范变更、维护者批准）
- 首席维护者 仅在有争议的治理决策或核心维护者无法达成共识时干预
升级矩阵
| 问题类型 | 第一升级 | 第二升级 | 时间线 |
|---|---|---|---|
| PR 中的技术分歧 | 范围内的维护者 | 核心维护者 | 5 个工作日 |
| 工作组中的技术分歧 | 工作组负责人 | 核心维护者 | 5 个工作日 |
| 兴趣组中的技术分歧 | 兴趣组协调员 | 核心维护者 | 5 个工作日 |
| 与工作组负责人/兴趣组协调员的分歧 | 核心维护者 | 首席维护者 | 7 个工作日 |
| 与维护者决策的分歧 | 核心维护者 | 首席维护者 | 7 个工作日 |
| 核心维护者分歧 | 首席维护者 | N/A | 10 个工作日 |
| 行为准则违规 | 社区管理员 | 核心维护者 | 立即 |
| 安全问题 | 核心维护者 | 首席维护者 | 立即 |
- 记录决策、考虑的选项和分歧点
- 向升级机构提出明确的请求
- 升级机构要么：(a) 提供具有约束力的指导，(b) 请求更多信息，或 (c) 如有需要进一步升级
贡献路径
MCP 重视多样化的贡献。以下是认可的晋升路径：代码贡献
- SDK 开发（TypeScript、Python 等）
- 测试基础设施
- 工具和开发者体验
规范工作
- 起草或完善规范文本
- SEP 作者或合著者
- 协议设计参与
- 兼容性分析
文档
- 用户指南和教程
- API 文档
- 架构文档
- 维护内容时效性
社区建设
- 引导新贡献者
- 工作组促进
- 社区支持（Discord、GitHub 讨论）
- 活动组织或代表
质量与安全
- Bug 分类和复现
- 安全审查和分析
- 测试覆盖率改进
- 发布验证
工作组与兴趣组领导
工作组 (WG) 负责人和兴趣组 (IG) 协调员是一种不需要维护者状态的特殊社区领导形式。工作组/兴趣组领导侧重于促进和协调，而不是合并权限。工作组和兴趣组的完整治理规则——包括参与层级、决策流程、会议要求和生命周期——在 SEP-2149: MCP 工作组治理与章程模板 中定义。 要求：- 最低成员状态
- 展示与工作组/兴趣组范围的持续参与
- 良好的促进和沟通技巧
- 能够公平地代表多种观点
- 小组及其领导由至少两名核心维护者或一名首席维护者推荐
- 工作组负责人和兴趣组协调员经验对晋升为维护者有价值
- 没有维护者状态的工作组负责人和兴趣组协调员与维护者合作进行合并决策
- 工作组负责人和兴趣组协调员对小组运营有权威，但对规范批准没有权威
- 工作组负责人和维护者可以推荐 SEP
- 工作组负责人可以在其范围领域内分类 SEP，包括关闭不符合工作组路线图的 SEP（需记录理由；作者可以向核心维护者上诉）
社区管理员
社区管理员是值得信赖的个人，帮助保持 MCP 社区健康、安全和受欢迎。这是一个专注于管理和行为准则执行而不是技术贡献的专用社区角色。 要求：- 最低成员状态
- 在社区互动中展现出良好的判断力和镇定
- 理解 MCP 行为准则和社区指南
- 能够谨慎和公平地处理敏感情况
- 由核心维护者或首席维护者推荐
- 监控社区渠道（Discord、GitHub 讨论等）以遵守行为准则
- 处理行为准则事件报告，包括初步分类和响应
- 将严重或复杂事件升级给核心维护者
- 帮助为所有社区成员维护一个欢迎和包容的环境
- 与其他管理员协调以确保持续执行
- 记录管理行动并保持事件细节的保密性
- 回避任何他们个人涉及的事件；此类事件由核心维护者直接处理
- 社区平台的管理权限（Discord、GitHub 讨论）
- 访问管理工具和私人管理渠道
- 有权对违反行为准则的用户发出警告、禁言或暂时封禁
- 列入社区管理员名单
- 社区管理员是并行路径，不是技术晋升的前提
- 管理员经验对晋升到任何角色都有价值，特别是在社区判断重要的地方
- 管理员可以同时持有其他角色（成员、维护者等）
认可与可见性
社区通过以下方式认可贡献者：- 贡献者名单 如
MAINTAINERS.md - GitHub 团队 用于适当的访问
- 发布说明中的公开致谢
- 社区活动的演讲机会
- 社区平台上的 徽章（如果实施）
卸任与荣誉状态
贡献者可以因任何原因从角色中卸任。这是正常且健康的。 流程：- 通知相关领导（工作组负责人、兴趣组协调员、维护者或核心维护者，视情况而定）
- 帮助过渡任何正在进行的工作
- 移至荣誉状态
- 因过去的贡献而受到认可
- 可以通过简化的重新引导返回活跃状态
- 无持续责任或权限
理由
为什么需要正式的阶梯？
非正式的晋升会导致不一致和不透明。正式的阶梯：- 为所有相关方设定清晰的期望
- 为讨论晋升提供共同的词汇
- 在晋升决策中建立问责制
- 支持自我提名，减少人为把关
为什么需要最低时间线？
时间线是底线，而非目标。它们存在于安全和信任建立的目的：- 信任是通过随着时间的推移所表现出的行为建立的
- 随着权限的快速提升，安全风险也会增加
- 对项目的深入理解需要持续的参与
- 行为模式只有在较长的时期内才会显现
为什么需要两个组织的赞助？
要求来自不同组织的赞助人：- 防止贡献者基础被单一组织俘获
- 确保贡献者在其雇主之外得到认可
- 在晋升决策中保持多样化的视角
模型灵感
此阶梯模型基于 Kubernetes 社区成员结构，并根据 MCP 的需求和发展阶段进行了调整。向后兼容性
本 SEP 建立了新流程，而未修改现有结构。当前贡献者保留其现有的访问权限和地位。安全影响
本 SEP 通过以下方式直接解决安全问题：- 具有时间线要求的分级权限提升
- 成员的双因素认证要求
- 多组织赞助以防止俘获
- 维护者的安全入职要求
参考实现
一旦被接受，本 SEP 将通过以下方式实施：- 将贡献者阶梯添加到
docs/community/contributor-ladder.mdx - 在
.github/ISSUE_TEMPLATE/中创建提名问题模板（参见附录中的清单模板） - 更新
MAINTAINERS.md格式以反映角色区别