> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 贡献者阶梯
> MCP 贡献者的角色、职责和晋升标准，从首次贡献到核心维护者
模型上下文协议贡献者阶梯定义了项目的角色、职责和晋升标准。它展示了社区成员如何从首次贡献成长为项目领导者。
本文档实现了 [SEP-2148](/seps/2148-contributor-ladder)。关于工作组和兴趣小组的治理，请参阅 [SEP-2149](/seps/2149-working-group-charter-template)。
## 指导原则
* **赢得信任。** 晋升源于展现出的贡献、良好的判断力和持续的参与。仅凭资历是不够的。
* **多种成长路径。** 代码、规范工作、文档和社区建设都能通向晋升。
* **透明度。** 晋升标准是明确的且一致应用的。
* **与 MCP 目标保持一致。** 贡献者必须表现出对 MCP 的承诺，超越任何单一雇主的利益。
## 角色一览
| 角色 | 摘要 | 关键权限 | 最短时间线 |
| --------------------------------- | -------------- | --------------------------------- | -------------- |
| [**贡献者**](#contributor) | 任何为 MCP 做出贡献的人 | 提交 Issue、PR，参与讨论 | 立即 |
| [**成员**](#member) | 既定的活跃贡献者 | GitHub 组织成员身份，分类权限，有资格担任 WG/IG 领导 | 2-3 个月有意义的贡献 |
| [**维护者**](#maintainer) | 具有运营责任的领域守护者 | 合并权限，参与发布 | 作为成员 6 个月以上 |
| [**核心维护者**](#core-maintainer) | 技术领导和协议守护 | 最终决策权，参与治理 | 持续维护者贡献后受邀 |
| [**首席维护者**](#lead-maintainer) | 最终项目权威（创始人） | 所有核心维护者权限，否决权，任命核心维护者 | 保留给项目创始人；仅继任 |
| [**社区协调员**](#community-moderator) | 行为准则执行和社区健康 | 社区平台协调权限，事件处理 | 并行轨道：成员状态 + 任命 |
时间线是最短要求，而非保证。它们保护项目免受权限快速
升级的影响，并确保展现出高标准的承诺。实际
晋升是酌情决定的，可能需要更长时间。例外情况需要明确
核心维护者批准并提供书面理由。
***
## 贡献者
任何以任何形式为 MCP 做出贡献的人都是贡献者。这包括开启 Issue、提交 pull request、参与工作组讨论、改进文档或帮助其他社区成员。
**没有正式要求。** 我们欢迎所有遵循我们贡献指南的贡献。
**入门指南：**
* 阅读 [贡献指南](/community/contributing)
* 加入社区频道（Discord, GitHub Discussions）
* 寻找标记为 `good-first-issue` 或 `help-wanted` 的 Issue
* 参加工作组会议
***
## 成员
成员是既定的贡献者，有记录显示对 MCP 的持续承诺。
**要求：**
* 对 MCP 有多次贡献（代码、文档和/或社区）
* 至少一个合并的 PR 或接受的贡献
* 与社区持续互动，不仅仅是一次性贡献
* GitHub 上启用双因素认证
* 7 天内现有成员无异议
**推荐：**
* 由来自不同组织的两名现有成员或维护者推荐，**或**
* 由一名核心维护者或首席维护者推荐
**最短时间线：** 2-3 个月的活跃参与
**职责：**
* 继续诚信贡献
* 响应分配的 Issue 和 PR
* 遵循社区指南和行为准则
* 尽可能帮助新贡献者上手
**权限：**
* 具有分类权限的 GitHub 组织成员身份
* 可被分配到 Issue 和 PR
* 可在 PR 上使用快捷批准或审查命令，如 `/lgtm`
* 列在社区成员名册中
* 可在受限仓库中创建 PR
* 有资格担任工作组负责人或兴趣小组协调员角色
**不活跃：** 3 个月无贡献的成员可能会被转为荣誉退休状态。重新参与遵循简化的重新熟悉流程。
***
## 维护者
维护者是值得信赖的守护者，对特定领域承担运营责任。
**要求：**
* 至少 6 个月的成员身份，持续高质量的贡献
* 在工作组或重大倡议中展现出领导力
* 能够代表 MCP 的利益高于任何单一雇主或组织的利益
* 深刻理解 MCP 愿景、路线图和设计原则
* 理解该领域如何影响现实世界的 AI 集成和模型交互模式
* 完成安全和治理入职培训
**推荐和批准：**
* 由现有维护者或核心维护者推荐
* 由核心维护者批准
**职责：**
* 拥有该领域的运营健康责任（测试稳定性、文档时效性）
* 运行发布流程和范围内的里程碑规划
* 提供及时审查升级的决策
* 积极参与治理讨论
* 指导成员并培养未来的维护者
* 在适当情况下在外部环境中代表 MCP
* 与该领域生态系统和利益相关者互动；了解现实世界的使用情况并代表社区需求
* 确保到达核心维护者的提案是经过提炼、深思熟虑的，并考虑到生态系统范围的影响
* 积极参与沟通渠道上的讨论（GitHub issues, Discord）
**权限：**
* 拥有领域的合并权限
* 可推荐新维护者
* 参与路线图和优先级讨论
* 列在 `MAINTAINERS.md` 中
**不活跃：** 6 个月无贡献的维护者经核心维护者审查后可能会被转为荣誉退休状态。转为荣誉退休时将撤销合并权限。重新参与需要再次完成安全和治理入职培训。
所有贡献路径都可以通向维护者。具体范围将与贡献类型保持一致。
***
## 核心维护者
核心维护者拥有 MCP 技术方向的最终决策权。这是社区中最高级别的信任。
核心维护者角色故意受限。这确保在项目扩展时技术
愿景的一致性。带宽问题通过委托给维护者、工作组负责人和兴趣小组
协调员来解决，而不是通过扩大核心维护者数量。
**要求：**
* 作为维护者或类似角色持续贡献至少 6 个月
* 在复杂的整个项目决策上展现出判断力
* 跨组织边界获得信任和尊重
* 深度承诺于 MCP 的长期成功
**任命：**
* 由多数核心维护者提名并由首席维护者批准，**或**
* 由首席维护者直接任命
在评估候选人时，核心维护者应考虑当前组成是否充分代表了 MCP 生态系统的广度。这包括在生产环境中部署 MCP 的企业采用者。
**职责：**
* 对有争议或跨领域问题的最终技术决策权
* 项目愿景和设计原则的守护
* 治理和政策决策
* MCP 的外部代表
* 继任计划和社区健康
* 确保协议演进中的克制和可持续性
* 参加核心维护者会议和聚会
**权限：**
* 对破坏性变更和主要规范修订的最终批准权
* 对 [SEP](/community/sep-guidelines) 的投票权
* 维护者的批准
* 治理投票权和参与治理的期望
* 所有 MCP GitHub 仓库的管理权限
* 在 `MAINTAINERS.md` 中列为核心维护者
**不活跃：** 6 个月未参与治理或技术决策的核心维护者经首席维护者审查后可能会被转为荣誉退休状态。鉴于该角色的可见性，核心维护者应主动沟通减少的可用性。
***
## 首席维护者
首席维护者拥有对 MCP 方向和治理的最终权威。这是保留给项目创始人的终身任命。没有通往此角色的晋升路径。它仅通过继任承担（请参阅 [继任](#succession)）。
**职责：**
* 所有核心维护者职责
* 任命和移除核心维护者
* 对有争议的治理决策的最终权威
* 项目范围的战略方向
**权限：**
* 在核心维护者需要多重批准的情况下可单独行动
* 对任何决策的否决权
* 任命继任者
### 继任
如果首席维护者因任何原因离开该角色，继任在其书面通知时开始。如果他们无法发出通知，剩余的首席维护者或核心维护者可以确定该首席维护者无法继续服务。
如果剩下一名或多名首席维护者，他们任命继任者。如果剩下一名以上，他们通过多数投票决定。剩余的首席维护者继续治理直到任命继任者。
如果没有首席维护者剩余，核心维护者在 30 天内通过多数投票任命继任者。在任命新的首席维护者之前，项目由核心维护者的三分之二投票运作。
***
## 社区管理员
社区管理员帮助保持 MCP 社区的健康、安全和友好。此角色侧重于调解和行为准则执行，而非技术贡献。
**要求：**
* 最低要求为成员身份
* 在社区互动中表现出良好的判断力和镇定
* 理解 MCP 行为准则和社区指南
* 能够谨慎且公平地处理敏感情况
**担保：**
* 由一名核心维护者或首席维护者担保
**职责：**
* 监控社区渠道（Discord、GitHub Discussions 等）以确保遵守行为准则
* 处理行为准则事件报告，包括初步分类和响应
* 将严重或复杂的事件升级给核心维护者
* 帮助维护友好和包容的环境
* 与其他管理员协调以确保执行的一致性
* 记录调解行动并对事件细节保密
* 回避任何涉及个人的事件；此类事件直接交由核心维护者处理
**权限：**
* 社区平台（Discord、GitHub Discussions）的调解权限
* 访问调解工具和私人调解渠道
* 有权对违反行为准则的用户发出警告、禁言或暂时封禁
* 列入社区管理员名单
**与贡献者阶梯的关系：** 社区管理员是一个平行轨道，不是技术晋升的先决条件。管理员经验计入任何角色，尤其是在需要社区判断力的地方。管理员可以同时担任其他角色（成员、维护者等）。
**移除：** 核心维护者可以因未能遵守调解标准或违反行为准则而移除社区管理员。管理员可以随时自愿卸任。
***
## 工作组和兴趣小组领导
工作组 (WG) 组长和兴趣小组 (IG) 协调人是一种不需要维护者身份的社区领导形式。工作组和兴趣小组的领导侧重于促进和协调，而非合并权限。
工作组和兴趣小组的完整治理规则定义在 [SEP-2149: MCP 群组治理和章程模板](/seps/2149-working-group-charter-template) 中。其中包括参与层级、决策流程、会议要求和生命周期。
**要求：**
* 最低要求为成员身份
* 表现出与小组范围的持续参与
* 良好的促进和沟通技巧
* 能够公平地代表多方观点
* 小组及其领导层由至少两名核心维护者或一名首席维护者担保
**与贡献者阶梯的关系：**
* 工作组组长和兴趣小组协调人经验对于晋升为维护者很有价值
* 没有维护者身份的组长和协调人与维护者合作进行合并决策
* 组长和协调人对小组运营拥有权限，但无权批准规范
* 工作组组长和维护者可以担保 SEP
* 工作组组长可以在其范围领域内筛选 SEP。这包括关闭不符合路线图的 SEP。关闭需要记录理由，作者可以向核心维护者申诉。
***
## 晋升流程
### 自我提名 vs. 推荐
贡献者可以：
1. **自我提名**，当他们认为自己符合要求时
2. **被提名**，由观察到其贡献的担保人提名
两条路径同样有效。鼓励自我提名。这显示了主动性和对自己贡献范围的自我认知。
### 流程步骤
1. **提名。** 被提名者或担保人使用提名模板打开一个 issue。它必须包括展示要求的贡献链接，以及担保确认。
2. **社区审查。** 随后有 7 天周期供社区输入意见。
3. **决策。** 批准权限方审查并决定。
4. **入职。** 新角色持有者获得适当的访问权限和入职指导。
| 晋升至 | 批准人 |
| ----- | --------------------------------- |
| 成员 | 2 名来自不同组织的现有成员+，**或** 1 名核心/首席维护者 |
| 维护者 | 1 名维护者或核心维护者担保 + 核心维护者批准 |
| 核心维护者 | 首席维护者 |
| 社区管理员 | 1 名核心维护者或首席维护者 |
自我提名的被提名者仍必须获得所需的担保。担保人在提名 issue 中确认支持。
***
## 决策与升级
### 默认委托
MCP 基于委托原则运作。决策应在最低的适当层级做出。这让项目能够快速推进，同时保留核心维护者的带宽用于跨领域问题。
* **维护者、工作组组长和兴趣小组协调人** 处理范围内的日常决策。
* **核心维护者** 在升级、跨领域问题或流程要求时（规范变更、维护者批准）介入。
* **首席维护者** 仅在有争议的治理决策或核心维护者无法达成共识时介入。
如有疑问，在你的层级做出决策并记录。仅在被阻塞、决策具有项目范围影响或流程明确要求时才升级。
工作组和兴趣小组争议的详细升级程序定义在 [SEP-2149 §1.5](/seps/2149-working-group-charter-template) 中。其中包括指定一名没有共同组织隶属关系的核心维护者来解决该问题。
### 升级矩阵
| 问题类型 | 第一级升级 | 第二级升级 | 时间线 |
| ----------------- | ------- | ----- | ------- |
| PR 中的技术分歧 | 范围内的维护者 | 核心维护者 | 5 个工作日 |
| 工作组中的技术分歧 | 工作组组长 | 核心维护者 | 5 个工作日 |
| 兴趣小组中的技术分歧 | 兴趣小组协调人 | 核心维护者 | 5 个工作日 |
| 与工作组组长/兴趣小组协调人的分歧 | 核心维护者 | 首席维护者 | 7 个工作日 |
| 与维护者决定的分歧 | 核心维护者 | 首席维护者 | 7 个工作日 |
| 核心维护者之间的分歧 | 首席维护者 | N/A | 10 个工作日 |
| 行为准则违规 | 社区管理员 | 核心维护者 | 立即 |
| 安全问题 | 核心维护者 | 首席维护者 | 立即 |
**升级流程：**
1. 记录决策、考虑的选项和分歧点
2. 向升级权限方提出明确的请求
3. 升级权限方要么 (a) 提供具有约束力的指导，(b) 请求更多信息，或 (c) 如有需要进一步升级
***
## 贡献路径
MCP 重视多样化的贡献。所有这些路径都可以导致晋升。
**代码贡献。** SDK 开发（TypeScript、Python 等）、测试基础设施、工具化和开发者体验。
**规范工作。** 起草或完善规范文本，[SEP](/community/sep-guidelines) 作者或合著者，协议设计参与，兼容性分析。
**文档。** 用户指南和教程，API 文档，架构文档，保持内容更新。
**社区建设。** 新贡献者入职，工作组促进，社区支持（Discord、GitHub discussions），活动组织或代表。
**质量与安全。** Bug 分类和复现，安全审查和分析，测试覆盖率改进，发布验证。
***
## 卸任与荣誉身份
贡献者可以因任何原因卸任角色。这是正常且健康的。
**流程：**
1. 通知相关领导层（工作组组长、兴趣小组协调人、维护者或核心维护者，视情况而定）
2. 帮助过渡任何正在进行的工作
3. 转为荣誉身份
**荣誉身份：**
* 因过去的贡献而受到认可
* 可以通过简化的重新入职流程返回活跃身份
* 无持续的责任或权限
**强制移除。** 角色可能因违反行为准则或持续不参与而被撤销。移除遵循适当的审查流程。
***
## 认可与可见性
社区通过以下方式认可贡献者：
* **贡献者列表** 例如 `MAINTAINERS.md`
* **GitHub 团队** 用于适当的访问权限
* **发布说明中的公开致谢**
* **社区活动的演讲机会**
* **徽章**（如果实施）在社区平台上