> ## 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. # 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](https://github.com/modelcontextprotocol/specification/pull/2148) ## 摘要 本 SEP 为模型上下文协议项目确立一套正式的贡献者阶梯，定义了从首次贡献者到核心维护者的清晰角色、职责和晋升标准。该阶梯为社区成员提供透明的路径，让他们理解如何在项目内增长其参与和影响力。 本 SEP 是 [SEP-2149：MCP 群组治理与章程模板](./2149-working-group-charter-template.md)的配套文件，后者定义了工作组和兴趣组如何运作。两个 SEP 相交：WG/IG 领导需要本阶梯上的成员身份，而群组参与是通往阶梯晋升的一条受认可的路径。 ## 动机 随着 MCP 采用度增长，项目需要一个清晰的框架来实现： 1. **贡献者发展**：社区成员对如何在 MCP 项目内增长其参与和影响力缺乏可见性。一套既定阶梯展示了从首次贡献到项目领导的路径。 2. **信任构建**：合并权限和其他高权限职责，是随时间通过已展现的承诺和良好判断力赢得的。分级体系确保贡献者在承担对项目更大的所有权之前，被准备好取得成功，并被既有维护者和更广泛社区所信任。 3. **组织多样性**：在有多个组织为 MCP 做贡献的情况下，项目需要机制来防止组织俘获，同时欢迎来自 Anthropic 之外的参与。 4. **可扩展性**：核心维护者的带宽有限。通过清晰的范围定义将权限委派给维护者和工作组/兴趣组 Lead，使项目能够扩展。 5. **认可**：贡献者在 MCP 上投入了大量精力。通过既定角色的正式认可承认他们的贡献，并鼓励持续的投入。 没有贡献者阶梯，晋升决策会变得临时、可能不一致，且对社区不透明。 ## 规范 ### 指导原则 贡献者阶梯在以下原则下运作： * **赢得的信任**：晋升基于已展现的、与项目目标一致的有意义贡献、良好判断力和持续投入，而非仅凭资历 * **多条成长路径**：代码、规范工作、文档和社区建设都能通向晋升 * **透明**：晋升标准是显式的，且被一致地应用 * **与 MCP 目标一致**：个人贡献者必须展现出推进和演进 MCP 项目组件、超越自身雇主利益的承诺 ### 角色定义 | 角色 | 概述 | 关键权限 | 最短时间线 | | --------------------------------- | ------------- | --------------------------------- | --------------- | | [**贡献者**](#contributor) | 任何为 MCP 做贡献的人 | 提交 issue、PR，参与讨论 | 立即 | | [**成员**](#member) | 有根基的、活跃的贡献者 | GitHub 组织成员身份、分诊权限、有资格担任 WG/IG 领导 | 2-3 个月有意义的贡献 | | [**维护者**](#maintainer) | 承担运营职责的领域管理者 | 合并权限、参与发布 | 作为成员满 6 个月以上 | | [**核心维护者**](#core-maintainer) | 技术领导和协议管理 | 最终决定权、参与治理 | 在持续的维护者贡献之后经邀请 | | [**首席维护者**](#lead-maintainer) | 项目的终极权威（创始人） | 全部核心维护者权限、否决权、任命核心维护者 | 保留给项目创始人——仅经继任 | | [**社区版主**](#community-moderators) | 行为准则执行和社区健康 | 社区平台上的审核权限、事件处理 | 平行轨道——成员身份 + 任命 | *所列时间线是最短贡献期，而非晋升保证。它们的存在是为了保护项目免于权限的快速升级，并确保已展现承诺的高门槛。实际晋升由酌情决定，实践中可能需要更长时间；唯一的保证是晋升不会以比所记录更短的时间尺度发生。对最短值的例外需要核心维护者附成文理由的明确批准。* ### 贡献者 任何以任何形式为 MCP 做过贡献的人都是贡献者。这包括： * 开 issue 或讨论 * 提交 pull request * 参与工作组讨论 * 改进文档 * 帮助其他社区成员 **没有正式要求**，我们欢迎所有贡献。 **如何开始：** * 查阅[贡献指南](https://modelcontextprotocol.io/community/contributing) * 加入社区渠道（Discord、GitHub Discussions） * 寻找标记为 `good-first-issue` 或 `help-wanted` 的 issue * 参加工作组会议 ### 成员 成员是有根基的贡献者，已展现出对 MCP 成功和成长的持续承诺。 **要求：** * 对 MCP 的多次贡献（代码、文档，及/或社区） * 至少一个已合并的 PR 或已被接受的贡献 * 与 MCP 社区的持续互动，而不仅是一次性的贡献 * 在 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 的技术方向持有最终决定权。这是社区中最高级别的信任。 *注：核心维护者角色被刻意限制，以在项目扩展的同时确保连贯的技术愿景。核心维护者的带宽顾虑通过向维护者、工作组 Lead 和兴趣组主持人更清晰地委派来解决，而非通过扩大核心维护者人数。* **要求：** * 作为维护者或类似角色至少 6 个月的持续贡献 * 在复杂的、项目全局的决策上展现出判断力 * 跨组织边界的信任和尊重 * 对 MCP 长期成功的深切承诺 **任命：** * 由多数核心维护者提名，经首席维护者批准 * 或由首席维护者直接任命 在评估候选人时，核心维护者应考虑当前的构成是否充分代表了 MCP 生态的广度，包括在生产领域部署 MCP 的企业采用者。 **职责：** * 对有争议的或跨领域的问题的最终技术决定权 * 对项目愿景和设计原则的管理 * 治理和政策决策 * MCP 的对外代表 * 继任规划和社区健康 * 确保协议演进中的克制和可持续性 * 参加核心维护者会议和核心维护者聚会 **权限：** * 对破坏性变更和重大规范修订的最终批准 * 对 [SEP](https://modelcontextprotocol.io/community/sep-guidelines)（规范增强提案）的投票权 * 对维护者的批准 * 治理投票权 / 参与治理的预期 * 对所有 MCP GitHub 仓库的管理员权限 * 在 `MAINTAINERS.md` 中列为核心维护者 **不活跃：** 6 个月未参与治理或技术决策的核心维护者，经首席维护者评审后可能被移至荣誉退任状态。鉴于此角色的信任和可见性，核心维护者应主动沟通其可用性的降低。 ### 首席维护者 首席维护者对 MCP 的方向和治理持有终极权威。这是保留给项目创始人的终身任命。没有通向此角色的既定晋升路径；它只能在必要时经继任承担（参见[继任](#succession)）。 **职责：** * 全部核心维护者职责 * 任命和移除核心维护者 * 对有争议治理决策的最终权威 * 项目全局的战略方向 **权限：** * 在核心维护者需要多方批准之处可以单独行动 * 对任何决策的否决权 * 任命继任者 ### 继任 如果首席维护者因任何原因离任，继任流程在其书面通知时开始；如果无法给出通知，则在剩余的首席维护者或核心维护者判定该首席维护者无法继续任职时开始。 如果仍有一位或多位首席维护者，他们应任命一位继任者（若为多人则以多数投票），剩余的首席维护者将继续治理，直至任命继任者。 如果没有首席维护者剩余，核心维护者应在 30 天内以多数投票任命一位继任者，在新的首席维护者被任命之前，项目以核心维护者的三分之二投票运作。 ### 晋升流程 #### 自我提名 vs. 认可 贡献者可以： 1. 在认为自己符合要求时**自我提名** 2. 由观察到其贡献的担保人**提名** 两条路径同等有效。鼓励并优先自我提名，因为它展现出主动性以及对贡献范围的自我认知。 #### 流程步骤 1. **提名**：被提名人或担保人使用提名模板开一个 issue，包含展现要求的贡献链接和担保人确认 2. **社区评审**：7 天的社区意见期 3. **决定**：批准权威者评审并决定 4. **上手**：新的角色持有者获得相应的访问权限和上手引导 | 晋升至 | 由谁批准 | | ----- | ------------------------------------ | | 成员 | 来自不同组织的 2 位现有成员及以上，**或** 1 位核心/首席维护者 | | 维护者 | 1 位维护者或核心维护者担保 + 核心维护者批准 | | 核心维护者 | 首席维护者 | | 社区版主 | 1 位核心维护者或首席维护者 | 鼓励自我提名，但被提名人仍必须获得所需的担保。担保人在提名 issue 中确认支持。 ### 决策与上报 #### 委派为默认 MCP 遵循委派原则运作：决策应在最低的适当层级作出。这使项目能够快速推进，同时为跨领域关切保留核心维护者的带宽。 * **维护者、WG Lead 和 IG 主持人**处理范围内的日常决策 * **核心维护者**在上报、跨领域问题，或流程要求时（规范变更、维护者批准）介入 * **首席维护者**仅在有争议的治理决策，或核心维护者无法达成共识时介入 存疑时，在你的层级作出决策并记录它。仅在受阻、决策具有项目全局影响，或流程明确要求时上报。 工作组和兴趣组争议的详细上报程序——包括指定一位无相同组织隶属的核心维护者来解决问题——在 [SEP-2149 §1.5](./2149-working-group-charter-template.md) 中定义。 #### 上报矩阵 | 问题类型 | 首次上报 | 二次上报 | 时间线 | | --------------------- | ------- | ----- | ------- | | 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](https://modelcontextprotocol.io/community/sep-guidelines) 撰写或联合撰写 * 参与协议设计 * 兼容性分析 #### 文档 * 用户指南和教程 * API 文档 * 架构文档 * 保持内容时效性 #### 社区建设 * 引导新贡献者上手 * 工作组主持 * 社区支持（Discord、GitHub discussions） * 活动组织或代表 #### 质量与安全 * 缺陷分诊和复现 * 安全评审和分析 * 测试覆盖改进 * 发布验证 ### 工作组和兴趣组领导 工作组（WG）Lead 和兴趣组（IG）主持人是一种不要求维护者身份的特殊社区领导形式。WG/IG 领导以主持和协调为中心，而非合并权限。WG 和 IG 的完整治理规则——包括参与层级、决策流程、会议要求和生命周期——在 [SEP-2149：MCP 群组治理与章程模板](./2149-working-group-charter-template.md)中定义。 **要求：** * 至少成员身份 * 已展现出对该 WG/IG 范围的持续投入 * 良好的主持和沟通技巧 * 有能力公平地代表多种视角 * 群组及其领导层由至少两位核心维护者或一位首席维护者担保 **与贡献者阶梯的关系：** * WG Lead 和 IG 主持人经验对晋升为维护者很有价值 * 没有维护者身份的 WG Lead 和 IG 主持人就合并决策与维护者协作 * WG Lead 和 IG 主持人对群组运营有权限，但对规范批准没有 * WG Lead 和维护者可以担保 SEP * WG Lead 可以分诊其范围领域内的 SEP，包括关闭不契合 WG 路线图的 SEP（附成文理由；作者可向核心维护者申诉） ### 社区版主 社区版主是帮助保持 MCP 社区健康、安全和友好的受信任个人。这是一个专注于审核和行为准则执行、而非技术贡献的专门社区角色。 **要求：** * 至少成员身份 * 在社区互动中展现出良好的判断力和沉稳 * 理解 MCP 行为准则和社区指南 * 有能力以谨慎和公平处理敏感情况 **担保：** * 由一位核心维护者或首席维护者担保 **职责：** * 监控社区渠道（Discord、GitHub Discussions 等）对行为准则的遵守 * 处理行为准则事件报告，包括初步分诊和响应 * 将严重或复杂的事件上报给核心维护者 * 帮助为所有社区成员维护友好和包容的环境 * 与其他版主协调以确保一致的执行 * 记录审核行动并对事件细节保密 * 在任何涉及其本人的事件中回避；此类事件直接由核心维护者处理 **权限：** * 社区平台（Discord、GitHub Discussions）上的审核权限 * 访问审核工具和私密审核频道 * 对违反行为准则者发出警告、禁言或临时封禁用户的权力 * 列于社区版主名录 **与贡献者阶梯的关系：** * 社区版主是一条平行轨道，而非技术晋升的前提 * 版主经验对晋升至任何角色都受重视，尤其在社区判断力重要之处 * 版主可以同时持有其他角色（成员、维护者等） **移除：** 核心维护者可因未能维护审核标准或因违反行为准则而移除社区版主。版主可以随时自愿卸任。 ### 认可与曝光 社区通过以下方式认可贡献者： * **贡献者列表**，例如 `MAINTAINERS.md` * 用于相应访问权限的 **GitHub 团队** * 发布说明中的**公开致谢** * 社区活动中的**演讲机会** * 社区平台上的**徽章**（如已实现） ### 卸任与荣誉退任状态 贡献者可因任何原因从角色卸任。这很正常且健康。 **流程：** 1. 通知相关领导（视情况为 WG Lead、IG 主持人、维护者或核心维护者） 2. 帮助交接任何进行中的工作 3. 转为荣誉退任状态 **荣誉退任：** * 因过去的贡献受到认可 * 可通过简略的重新上手回到活跃状态 * 没有持续的职责或权限 **非自愿移除：** 在违反行为准则或持续不参与的情况下，角色可在适当的评审流程后被撤销。 ## 理由 ### 为何要正式阶梯？ 非正式晋升造成不一致和不透明。正式阶梯： * 为各方设定清晰的预期 * 为讨论晋升提供共同的词汇 * 在晋升决策中创造问责 * 支持自我提名，减少把关 ### 为何要最短时间线？ 时间线是下限，而非目标。它们的存在是为了安全和信任构建： * 信任是随时间通过已展现的行为构建的 * 安全风险随权限的快速升级而增加 * 对项目的深刻理解需要持续投入 * 行为模式只在较长时期后才变得可见 满足最短时间线并不创设晋升的权利；它确立了被考虑的资格。对最短值的例外需要核心维护者附成文理由的明确批准。 ### 为何要两个组织的担保？ 要求来自不同组织的担保人： * 防止贡献者基础被组织俘获 * 确保贡献者获得超越其雇主的认可 * 在晋升决策中保持多样化视角 ### 模型灵感 本阶梯以 Kubernetes 社区成员结构为蓝本，并为 MCP 的需求和发展阶段作了调整。 ## 向后兼容性 本 SEP 确立新流程，不修改既有结构。当前贡献者保留其既有的访问权限和地位。 ## 安全影响 本 SEP 通过以下方式直接针对安全： * 带时间线要求的分级权限升级 * 对成员的双因素认证要求 * 多组织担保以防止俘获 * 对维护者的安全上手要求 ## 参考实现 一经接受，本 SEP 将通过以下方式实现： 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 ```