MCP 社区
治理与管理

治理与管理

社区译文；来源： MCP 80041ab0

Model Context Protocol（MCP）采用正式治理模型，以确保决策透明和社区参与。本文说明项目的组织方式和决策方式。

项目通用政策

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

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

除下述情况外，项目的所有代码和规范贡献都必须使用 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 及其他开源项目类似的分层结构：

角色范围
Lead Maintainers (BDFL)最终决策权
Core Maintainers项目整体方向
Maintainers工作组、SDK、组件
ContributorsIssue、PR、讨论
  • 贡献者提交 issue、发起 pull request 并为项目作出贡献。
  • 维护者推动 MCP 项目内的组件，例如 SDK、文档和工作组。
  • 核心维护者推动项目整体方向，并监督贡献者和维护者。
  • Lead Maintainer 是最终决策者（也称 BDFL，即 Benevolent Dictator for Life）。

维护者、核心维护者和 Lead Maintainer 共同组成 MCP Steering Group。

所有维护者都应高度认同 MCP 的设计理念。技术治理流程中的成员资格授予个人，而不是公司。换言之，不为特定公司保留席位，成员资格归属于个人，而不是其雇主。

沟通渠道

技术治理通过所有维护者共享的 Discord 服务器 开展。每个维护者小组可以选择其他沟通渠道，但所有决定及其支撑讨论都必须记录并在 Discord 服务器上透明公开。

角色

贡献者阶梯 是各角色的规范定义，包括要求、职责、权限、晋升流程和失活政策。本节从概念上概述各角色与治理的关系。

维护者负责 SDK、文档或工作组 等具体领域。他们独立作出本领域决策，并在必要时上报核心维护者。维护者拥有相应仓库的写入权限。

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

Lead Maintainer 拥有最终权力，可以否决核心维护者或维护者的任何决定；该角色通常称为 Benevolent Dictator for Life（BDFL）。Lead Maintainer 任命和移除核心维护者，并且是所有项目基础设施的管理员。他们属于核心维护者小组，并应公开阐述其理由。

贡献者阶梯 还定义了位于 Steering Group 之外的 Member 和 Community Moderator 角色。

决策流程

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

Lead Maintainer、核心维护者和维护者群体应争取每三至六个月线下会面一次。

流程

核心维护者和 Lead Maintainer 负责 Model Context Protocol 的所有方面，包括文档、issue、内容建议以及 MCP 项目 下的其他全部内容。维护者负责其所辖 MCP 项目领域的文档、issue 和内容建议，也鼓励参与 MCP 各项目的一般维护。

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

工作组和兴趣组

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

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

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

规范增强提案（SEP）

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

完整的 SEP 流程、格式要求和状态工作流参见 SEP 指南 。

维护职责

没有专属维护者的组件（例如文档）由核心维护者负责。这些组件通过 pull request 遵循标准贡献指南，由维护者处理评审，并将任何重大变更上报核心维护者评审。

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

沟通

核心维护者会议

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

公共聊天

MCP 项目维护一个公开 Discord 服务器 ，其中设有面向兴趣组的公开聊天频道。MCP 项目可能为某些沟通设置私有频道。

提名、确认和移除维护者

维护者小组成员资格根据个人已证明的专业能力及其与 MCP 方向的一致性，按贡献授予个人。成员资格归属于个人而非其雇主，且没有任期限制。

各角色的提名流程、发起要求、评审时间线和失活条件由贡献者阶梯的晋升流程 定义。

当前 Lead Maintainer

  • David Soria Parra
  • Den Delimarsky

当前核心维护者

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

荣休成员

  • Justin Spahr-Summers（共同发明者，Lead Maintainer Emeritus）
  • Basil Hosmer（Core Maintainer Emeritus）
  • Che Liu（Core Maintainer Emeritus）
  • Nick Aldridge（Core Maintainer Emeritus）

当前维护者和工作组

参见维护者列表 。

为 MCP 作贡献