治理与维护

了解 Model Context Protocol 的治理结构以及如何参与社区

Model Context Protocol (MCP) 遵循正式的治理模型，以确保决策透明和社区参与。本文档概述了项目的组织方式以及决策的制定方式。

项目通用政策

Model Context Protocol 已设立为 Model Context Protocol a Series of LF Projects, LLC。适用于 Model Context Protocol 及 Model Context Protocol 参与者的政策（包括商标使用指南）位于 https://www.lfprojects.org/policies/。根据本治理文件的规定获批的治理变更，也必须获得 LF Projects, LLC 的批准。

Model Context Protocol 参与者确认，所有新贡献的版权将由版权持有者作为独立著作保留，任何贡献者或版权持有者均无需向本项目转让版权。

除下文所述情况外，向本项目提交的所有代码和规范贡献 MUST（必须）使用 Apache License, Version 2.0（可在此获取：https://www.apache.org/licenses/LICENSE-2.0）（即"项目许可证"）。

所有对外发布的代码和规范将依据项目许可证提供。核心维护者可例外批准对入站或出站贡献使用替代开源许可证。

所有文档（规范除外）将依据 Creative Commons Attribution 4.0 International 许可证提供，可在此获取：https://creativecommons.org/licenses/by/4.0。

技术治理

MCP 项目采用分层结构，类似于 Python、PyTorch 及其他开源项目：

角色	范围
首席维护者 (BDFL)	最终决策权
核心维护者	项目整体方向
维护者	工作组、SDK、组件
贡献者	Issue、PR、讨论

贡献者提交 issue、发起 pull request，并为项目做出贡献。
维护者推动 MCP 项目内的组件，例如 SDK、文档和工作组。
核心维护者推动项目整体方向，并监督贡献者和维护者。
首席维护者是最终决策者（也称为 BDFL - Benevolent Dictator for Life）。

维护者、核心维护者和首席维护者共同组成 MCP 指导组。

所有维护者都应对 MCP 的设计理念有强烈的认同倾向。技术治理流程中的成员资格属于个人，而非公司。也就是说，不为特定公司保留席位，成员资格与个人相关联，而非与其所供职的公司相关联。

沟通渠道

技术治理通过所有维护者共享的 Discord 服务器进行。每个维护者小组可以选择额外的沟通渠道，但所有决策及其支撑性讨论 MUST（必须）记录并在 Discord 服务器上透明地提供。

角色

贡献者阶梯是每个角色的权威定义——包括其要求、职责、特权、晋升流程和不活跃政策。本节从概念上概述各角色与治理的关系。

维护者管理特定领域，例如 SDK、文档或工作组。他们独立为自己的领域做出决策，并在需要时上报给核心维护者。维护者对其各自的仓库拥有写入权限。

核心维护者主导 MCP 规范和项目整体方向。他们可以通过多数投票否决维护者的决定、解决争议，并任命或罢免维护者。核心维护者对所有 MCP 仓库拥有管理员权限，但与外部贡献者使用相同的 pull request 工作流。

首席维护者拥有最终权威，可以否决核心维护者或维护者的任何决定——这一角色通常被称为 Benevolent Dictator for Life (BDFL)。首席维护者任命和罢免核心维护者，并且是所有项目基础设施的管理员。他们属于核心维护者小组，并应公开阐述其决策理由。

贡献者阶梯还定义了 Member 和 Community Moderator 角色，它们不属于指导组。

决策流程

核心维护者小组每两周召开一次会议，讨论并投票表决提案，以及讨论任何需要讨论的话题。如有需要，共享的 Discord 服务器可用于讨论和投票表决较小的提案。

首席维护者、核心维护者和维护者小组应尝试每三到六个月进行一次线下会面。

流程

核心维护者和首席维护者负责 Model Context Protocol 的所有方面，包括文档、issue、内容建议以及 MCP 项目下的所有其他部分。维护者负责其所在 MCP 项目领域的文档、issue 和内容建议，但鼓励他们参与 MCP 项目的一般性维护工作。

维护者、核心维护者和首席维护者应使用与外部贡献者相同的贡献流程，而不是直接对仓库进行更改。这有助于了解意图并提供讨论机会。

工作组和兴趣小组

MCP 的协作与贡献围绕两个结构组织：工作组和兴趣小组。

兴趣小组通过公开讨论识别并阐明 MCP 应解决的问题
工作组通过产出 SEP 或实现等交付物来开发具体解决方案

有关如何创建、参与和推动这些小组的详细信息，请参阅工作组和兴趣小组文档。

规范增强提案（SEP）

对规范的拟议更改必须以规范增强提案（SEP）的形式提交。SEP 是提出重大新功能、收集社区意见和记录设计决策的主要机制。

有关完整的 SEP 流程、格式要求和状态工作流，请参阅 SEP 指南。

维护职责

没有专门维护者的组件（如文档）由核心维护者负责。这些组件遵循标准的贡献指南，通过拉取请求进行，由维护者负责审查，任何重大更改都需上报核心维护者审查。

鼓励核心维护者和维护者改进 MCP 项目的任何部分，无论正式的维护分工如何。

沟通

核心维护者会议

核心维护者小组每两周召开一次会议，讨论提案和项目事宜。提案相关记录应公开。核心维护者小组将力争每 3-6 个月举行一次线下会议。

公开聊天

MCP 项目维护着一个公开 Discord 服务器，为兴趣小组提供公开聊天。MCP 项目可能设有用于特定沟通的私有频道。

维护者的提名、确认和移除

维护者小组的成员资格授予个人，基于其展现出的专业能力以及与 MCP 方向的一致性，择优授予。成员资格与个人关联，而非其雇主，且没有任期限制。

各角色的提名流程、赞助要求、审查时间线和 inactivity 标准定义在贡献者阶梯的晋升流程中。

现任首席维护者

David Soria Parra
Den Delimarsky

现任核心维护者

Peter Alexander
Caitie McCaffrey
Kurtis Van Gent
Clare Liguori
Paul Carleton
Nick Cooper

荣休成员

Justin Spahr-Summers（联合发明人，荣休首席维护者）
Basil Hosmer（荣休核心维护者）
Che Liu（荣休核心维护者）
Nick Aldridge（荣休核心维护者）

现任维护者和工作组

请参阅维护者列表。