贡献者阶梯

社区译文；来源： MCP 80041ab0

Model Context Protocol 贡献者阶梯定义了项目角色、职责和晋升标准，说明社区成员如何从首次贡献逐步参与到项目领导工作。

本文落实 SEP-2148（英文）。工作组和兴趣组治理参见 SEP-2149（英文）。

指导原则

• **赢得信任。**晋升取决于已证明的贡献、良好判断和持续参与。仅有资历并不足够。
• **多种成长路径。**代码、规范工作、文档和社区建设都可以带来晋升。
• **透明。**晋升标准明确且一致适用。
• **与 MCP 目标一致。**贡献者必须表明其对 MCP 的投入超越任何单一雇主的利益。

角色概览

Contributor

任何以任何形式为 MCP 作出贡献的人都是 Contributor，包括创建 issue、提交 pull request、参加工作组讨论、改进文档或帮助其他社区成员。

**没有正式要求。**我们欢迎所有遵循贡献指南的贡献。

开始参与：

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

Member

Member 是已有持续投入记录的成熟贡献者。

要求：

• 多次为 MCP 作出贡献（代码、文档和/或社区）
• 至少有一个已合并 PR 或被接受的贡献
• 持续参与社区，而不是仅作出一次性贡献
• GitHub 已启用双因素认证
• 现有 Member 在 7 天内无人反对

发起：

• 由来自不同组织的两名现有 Member 或 Maintainer 发起，或者
• 由一名 Core Maintainer 或 Lead Maintainer 发起

**最短时间线：**活跃参与 2-3 个月

职责：

• 持续善意贡献
• 响应分配给自己的 issue 和 PR
• 遵循社区指南和行为准则
• 在可能时帮助新贡献者入门

权限：

• 成为 GitHub 组织成员并拥有分类权限
• 可以被指派处理 issue 和 PR
• 可以在 PR 上使用快捷批准或评审命令，例如 /lgtm
• 列入社区成员名册
• 可以在受限仓库中创建 PR
• 有资格担任工作组 Lead 或兴趣组 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

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

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

Core Maintainer

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

要求：

• 作为 Maintainer 或类似角色持续贡献至少 6 个月
• 在复杂、影响整个项目的决定中表现出良好判断
• 获得跨组织的信任和尊重
• 对 MCP 的长期成功有深度投入

任命：

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

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

职责：

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

权限：

• 最终批准破坏性变更和重大规范修订
• 对 SEP 拥有投票权
• 批准 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 继续治理。

如果已无 Lead Maintainer，Core Maintainer 应在 30 天内以多数票任命继任者。在新 Lead Maintainer 获任命前，项目由 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 可以随时自愿卸任。

工作组和兴趣组领导

工作组（WG）Lead 和兴趣组（IG）Facilitator 属于社区领导角色，不要求具备 Maintainer 身份。WG 和 IG 的领导工作以促进和协调为中心，而不是合并权限。

WG 和 IG 的完整治理规则定义于 SEP-2149：MCP Group Governance and Charter Template（英文），包括参与等级、决策流程、会议要求和生命周期。

要求：

• 至少具备 Member 身份
• 已证明持续参与该小组的范围
• 良好的促进和沟通能力
• 能够公平代表多种观点
• 小组及其领导层由至少两名 Core Maintainer 或一名 Lead Maintainer 发起

与贡献者阶梯的关系：

• WG Lead 和 IG Facilitator 经历对晋升 Maintainer 很有价值
• 不具备 Maintainer 身份的 Lead 和 Facilitator 与 Maintainer 协作处理合并决定
• Lead 和 Facilitator 对小组运营有权限，但无权批准规范
• WG Lead 和 Maintainer 可以发起 SEP
• WG Lead 可以分类处理其范围内的 SEP，包括关闭不符合路线图的 SEP。关闭必须记录理由，作者可以向 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 无法达成共识时介入。

不确定时，在自己的层级作出决定并记录。仅当工作受阻、决定影响整个项目，或流程明确要求时才上报。

工作组和兴趣组争议的详细上报程序定义于 SEP-2149 §1.5（英文），其中规定由与争议方不存在共同组织隶属关系的 Core Maintainer 解决问题。

上报矩阵

上报流程：

1. 记录决定、考虑过的选项和分歧点
2. 向上报受理者说明明确诉求
3. 上报受理者可以：(a) 给出有约束力的指导，(b) 要求更多信息，或 (c) 在必要时继续上报

贡献路径

MCP 重视多样化贡献。以下所有路径都可以带来晋升。

**代码贡献。**SDK 开发（TypeScript、Python 等）、测试基础设施、工具和开发者体验。

**规范工作。**起草或完善规范文本、撰写或共同撰写 SEP、参与协议设计、兼容性分析。

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

**社区建设。**帮助新贡献者入门、促进工作组、社区支持（Discord、GitHub discussions）、组织活动或代表社区参加活动。

**质量与安全。**错误分类和复现、安全评审与分析、改进测试覆盖率、发布验证。

卸任与 Emeritus 状态

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

流程：

1. 通知相应领导者（视情况为 WG Lead、IG Facilitator、Maintainer 或 Core Maintainer）
2. 帮助交接正在进行的工作
3. 转为 emeritus 状态

Emeritus 状态：

• 认可过去的贡献
• 可以通过简化的重新入门流程恢复活跃状态
• 不再承担持续职责或享有权限

**非自愿移除。**角色可能因违反行为准则或长期不参与而被撤销。移除遵循适当的评审流程。

认可与展示

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

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