> ## 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.

# 治理与管理

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

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

## 一般项目政策

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

Model Context Protocol 参与者承认，所有新贡献的版权将由版权所有者作为独立的作者作品保留，并且不要求任何贡献者或版权所有者将版权转让给项目。

除下文所述外，对项目的所有代码和规范贡献必须使用 Apache 许可证 2.0 版（此处可用：[https://www.apache.org/licenses/LICENSE-2.0](https://www.apache.org/licenses/LICENSE-2.0)）（“项目许可证”）。

所有出站代码和规范将在项目许可证下提供。核心维护者可以在例外情况下批准使用替代的开源许可证用于入站或出站贡献。

所有文档（不包括规范）将根据 Creative Commons Attribution 4.0 International 许可证提供，地址：[https://creativecommons.org/licenses/by/4.0。](https://creativecommons.org/licenses/by/4.0。)

## 技术治理

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

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

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

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

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

### 沟通渠道

技术治理通过所有维护者共享的 [Discord 服务器](https://discord.gg/6CSzBmMkjX) 进行促进。每个维护者组可以选择额外的沟通渠道，但所有决策及其支持性讨论必须记录并在 Discord 服务器上透明公开。

### 角色

[贡献者阶梯](/community/contributor-ladder) 是每个角色的规范定义——其要求、职责、特权、晋升流程和不活跃政策。本节概述了角色如何与治理相关联的概念。

**维护者** 管理特定领域，如 SDK、文档或 [工作组](/community/working-interest-groups)。他们独立为其领域做出决策，并在需要时升级至核心维护者。维护者拥有各自仓库的写入权限。

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

**首席维护者** 拥有最终权威，可以否决核心维护者或维护者的任何决策——该角色通常称为终身仁慈独裁者 (BDFL)。首席维护者任命和移除核心维护者，并且是所有项目基础设施的管理员。他们是核心维护者组的一部分，并期望公开阐述其理由。

[贡献者阶梯](/community/contributor-ladder) 还定义了 **成员** 和 **社区版主** 角色，它们位于指导小组之外。

### 决策流程

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

首席维护者、核心维护者和维护者组应尝试每三到六个月亲自见面一次。

## 流程

核心维护者和首席维护者负责 Model Context Protocol 的所有方面，包括文档、issue、内容建议以及 [MCP 项目](https://github.com/modelcontextprotocol) 下的所有其他部分。维护者负责其 MCP 项目领域的文档、issue 和内容建议，但鼓励参与 MCP 项目的一般维护。

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

### 工作组和兴趣组

MCP 协作和贡献围绕两个结构组织：[工作组和兴趣组](/community/working-interest-groups)。

* **兴趣组** 通过公开讨论识别并阐述 MCP 应解决的问题
* **工作组** 通过产生交付物（如 SEP 或实现）来开发具体解决方案

有关如何创建、参与和促进这些组的详细信息，请参阅 [工作组和兴趣组](/community/working-interest-groups) 文档。

### 规范增强提案 (SEPs)

对规范的拟议变更必须作为 [规范增强提案 (SEPs)](/community/sep-guidelines) 提交。SEPs 是提议主要新功能、收集社区输入和记录设计决策的主要机制。

有关完整的 SEP 流程、格式要求和状态工作流，请参阅 [SEP 指南](/community/sep-guidelines)。

### 维护职责

没有专门维护者的组件（如文档）属于核心维护者责任。这些通过 pull request 遵循标准贡献指南，维护者处理审查，并将任何重大变更升级至核心维护者审查。

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

## 沟通

### 核心维护者会议

核心维护者组每两周开会一次，讨论提案和项目。提案笔记应公开。核心维护者组将努力每 3-6 个月亲自见面一次。

### 公共聊天

MCP 项目维护一个 [公共 Discord 服务器](https://discord.gg/6CSzBmMkjX)，设有兴趣组的公开聊天。MCP 项目可能设有用于某些通信的私人渠道。

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

维护者组的成员资格是基于功绩授予**个人**的，需经过证实的专业知识并与 MCP 的方向保持一致。成员资格与个人相关联，而非其雇主，且没有任期限制。

每个角色的提名流程、赞助要求、审查时间表和不活跃标准在 [贡献者阶梯的晋升流程](/community/contributor-ladder#advancement-process) 中定义。

## 现任首席维护者

* David Soria Parra
* Den Delimarsky

## 现任核心维护者

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

## 名誉成员

* Justin Spahr-Summers (Co-Inventor, Lead Maintainer Emeritus)
* Basil Hosmer (Core Maintainer Emeritus)
* Che Liu (Core Maintainer Emeritus)

## 现任维护者和工作组

请参阅 [维护者列表](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md)。