> ## Documentation Index
> Fetch the complete documentation index at: https://mcp-zh.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 的承诺，超越任何单一雇主的利益。

## 角色一览

| 角色                  | 概述            | 关键权限                              | 最短时间线          |
| ------------------- | ------------- | --------------------------------- | -------------- |
| [**贡献者**](#贡献者)     | 任何为 MCP 做贡献的人 | 提交 issue、PR，参与讨论                  | 立即             |
| [**成员**](#成员)       | 有根基的、活跃的贡献者   | GitHub 组织成员身份、分诊权限、有资格担任 WG/IG 领导 | 2-3 个月有意义的贡献   |
| [**维护者**](#维护者)     | 承担运营职责的领域管理者  | 合并权限、参与发布                         | 作为成员满 6 个月以上   |
| [**核心维护者**](#核心维护者) | 技术领导和协议管理     | 最终决定权、参与治理                        | 在持续的维护者贡献之后经邀请 |
| [**首席维护者**](#首席维护者) | 项目的终极权威（创始人）  | 全部核心维护者权限、否决权、任命核心维护者             | 保留给项目创始人；仅经继任  |
| [**社区版主**](#社区版主)   | 行为准则执行和社区健康   | 社区平台上的审核权限、事件处理                   | 平行轨道：成员身份 + 任命 |

<Note>
  时间线是最短值，而非保证。它们保护项目免于权限的快速升级，并确保已展现承诺的高门槛。实际的晋升由酌情决定，可能需要更长时间。例外情况需要核心维护者附成文理由的明确批准。
</Note>

***

## 贡献者

任何以任何形式为 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
* 有资格担任工作组 Lead 或兴趣组主持人角色

**不活跃：** 3 个月无贡献的成员可能被移至荣誉退任状态。重新参与遵循一个简化的重新熟悉流程。

***

## 维护者

维护者是受信任的管理者，为特定领域承担运营职责。

**要求：**

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

**担保与批准：**

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

**职责：**

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

**权限：**

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

**不活跃：** 6 个月无贡献的维护者，经核心维护者评审后可能被移至荣誉退任状态。转为荣誉退任时合并权限被撤销。重新参与需要再次完成安全和治理上手培训。

所有贡献路径都能通向维护者。具体范围将与贡献类型相符。

***

## 核心维护者

核心维护者对 MCP 的技术方向持有最终决定权。这是社区中最高级别的信任。

<Note>
  核心维护者角色被刻意限制。这确保在项目扩展的同时保持连贯的技术愿景。带宽方面的顾虑通过向维护者、工作组 Lead 和兴趣组主持人委派来解决，而非通过扩大核心维护者人数。
</Note>

**要求：**

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

**任命：**

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

在评估候选人时，核心维护者应考虑当前的构成是否充分代表了 MCP 生态的广度。这包括在生产中部署 MCP 的企业采用者。

**职责：**

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

**权限：**

* 对破坏性变更和重大规范修订的最终批准
* 对 [SEP](/community/sep-guidelines) 的投票权
* 对维护者的批准
* 治理投票权，以及参与治理的预期
* 对所有 MCP GitHub 仓库的管理员权限
* 在 `MAINTAINERS.md` 中列为核心维护者

**不活跃：** 6 个月未参与治理或技术决策的核心维护者，经首席维护者评审后可能被移至荣誉退任状态。鉴于此角色的可见性，核心维护者应主动沟通其可用性的降低。

***

## 首席维护者

首席维护者对 MCP 的方向和治理持有终极权威。这是保留给项目创始人的终身任命。没有通向此角色的晋升路径。它只能经继任承担（参见[继任](#继任)）。

**职责：**

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

**权限：**

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

### 继任

如果一位首席维护者因任何原因离任，继任在其书面通知时开始。如果他们无法给出通知，剩余的首席维护者或核心维护者可以判定该首席维护者无法继续任职。

如果仍有一位或多位首席维护者，他们任命一位继任者。如果剩余多于一位，他们以多数投票决定。剩余的首席维护者继续治理，直至任命继任者。

如果没有首席维护者剩余，核心维护者在 30 天内以多数投票任命一位继任者。在新的首席维护者被任命之前，项目以核心维护者的三分之二投票运作。

***

## 社区版主

社区版主帮助保持 MCP 社区的健康、安全和友好。此角色聚焦于审核和行为准则执行，而非技术贡献。

**要求：**

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

**担保：**

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

**职责：**

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

**权限：**

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

**与贡献者阶梯的关系：** 社区版主是一条平行轨道，而非技术晋升的前提。版主经验计入任何角色，尤其在社区判断力重要之处。版主可以同时持有其他角色（成员、维护者等）。

**移除：** 核心维护者可因未能维护审核标准或因违反行为准则而移除社区版主。版主可以随时自愿卸任。

***

## 工作组和兴趣组领导

工作组（WG）Lead 和兴趣组（IG）主持人是一种不要求维护者身份的社区领导形式。WG 和 IG 领导以主持和协调为中心，而非合并权限。

WG 和 IG 的完整治理规则在 [SEP-2149：MCP 群组治理与章程模板](/seps/2149-working-group-charter-template)中定义。这些包括参与层级、决策流程、会议要求和生命周期。

**要求：**

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

**与贡献者阶梯的关系：**

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

***

## 晋升流程

### 自我提名 vs. 认可

贡献者可以：

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

两条路径同等有效。鼓励自我提名。它展现出主动性以及对自身贡献范围的自我认知。

### 流程步骤

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

| 晋升至   | 由谁批准                                 |
| ----- | ------------------------------------ |
| 成员    | 来自不同组织的 2 位现有成员及以上，**或** 1 位核心/首席维护者 |
| 维护者   | 1 位维护者或核心维护者担保 + 核心维护者批准             |
| 核心维护者 | 首席维护者                                |
| 社区版主  | 1 位核心维护者或首席维护者                       |

自我提名的被提名人仍必须获得所需的担保。担保人在提名 issue 中确认支持。

***

## 决策与上报

### 委派为默认

MCP 遵循委派原则运作。决策应在最低的适当层级作出。这让项目能够快速推进，同时为跨领域关切保留核心维护者的带宽。

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

存疑时，在你的层级作出决策并记录它。仅在受阻、决策具有项目全局影响，或流程明确要求时上报。

工作组和兴趣组争议的详细上报程序在 [SEP-2149 §1.5](/seps/2149-working-group-charter-template) 中定义。它包括指定一位无相同组织隶属的核心维护者来解决问题。

### 上报矩阵

| 问题类型                  | 首次上报    | 二次上报  | 时间线     |
| --------------------- | ------- | ----- | ------- |
| PR 中的技术分歧             | 范围内的维护者 | 核心维护者 | 5 个工作日  |
| WG 中的技术分歧             | WG Lead | 核心维护者 | 5 个工作日  |
| IG 中的技术分歧             | IG 主持人  | 核心维护者 | 5 个工作日  |
| 与 WG Lead / IG 主持人的分歧 | 核心维护者   | 首席维护者 | 7 个工作日  |
| 与维护者决策的分歧             | 核心维护者   | 首席维护者 | 7 个工作日  |
| 核心维护者之间的分歧            | 首席维护者   | 不适用   | 10 个工作日 |
| 违反行为准则                | 社区版主    | 核心维护者 | 立即      |
| 安全问题                  | 核心维护者   | 首席维护者 | 立即      |

**上报流程：**

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

***

## 贡献路径

MCP 重视多样化的贡献。以下所有路径都能通向晋升。

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

**规范工作。** 起草或完善规范文本、[SEP](/community/sep-guidelines) 撰写或联合撰写、参与协议设计、兼容性分析。

**文档。** 用户指南和教程、API 文档、架构文档、保持内容最新。

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

**质量与安全。** 缺陷分诊和复现、安全评审和分析、测试覆盖改进、发布验证。

***

## 卸任与荣誉退任状态

贡献者可因任何原因从角色卸任。这很正常且健康。

**流程：**

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

**荣誉退任状态：**

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

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

***

## 认可与曝光

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

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