> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.gjxx.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 治理和管理

> 了解模型上下文协议的治理结构以及如何参与社区

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

## 技术治理

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

* **贡献者**社区，他们提交问题、创建拉取请求并为项目做出贡献。
* 一小组**维护者**驱动 MCP 项目内的组件，例如 SDK、文档等。
* 贡献者和维护者由**核心维护者**监督，他们驱动整体项目方向。
* 核心维护者有两位**首席核心维护者**，他们是包罗万象的决策制定者。
* 维护者、核心维护者和首席核心维护者组成**MCP 指导小组**。

所有维护者都应强烈倾向于 MCP 的设计理念。技术治理过程中的成员资格是针对个人的，而不是公司的。也就是说，没有为特定公司保留席位，成员资格与个人相关联，而不是雇用该人的公司。这确保维护者为协议本身和开源社区的最佳利益行事。

### 渠道

技术治理通过所有**维护者、核心维护者和首席维护者**共享的 [Discord 服务器](/community/communication#discord) 进行协调。每个维护者小组可以选择额外的沟通渠道，但所有决策及其支持讨论必须在 Discord 服务器上记录并透明公开。

### 维护者

维护者负责 MCP 项目内的[工作组或兴趣小组](/community/working-interest-groups)。这些通常是独立的仓库，例如特定语言的 SDK，但也可以扩展到仓库的子目录，例如 MCP 文档。维护者可以采用自己的规则和程序来做出决策。维护者应独立为各自项目做出决策，但可在需要时推迟或升级到核心维护者。

维护者负责：

* 与社区贡献者进行深思熟虑和富有成效的互动，
* 维护和改进 MCP 项目的各自领域，
* 支持文档、路线图和其他 MCP 项目的相邻部分，
* 将社区想法呈现给核心。

维护者应在需要时提出额外维护者。维护者只能由核心维护者或首席核心维护者随时任命和移除，无需理由。

维护者对各自仓库拥有写入和/或管理员访问权限。

### 核心维护者

核心维护者应深入了解模型上下文协议及其规范。他们的职责包括：

* 设计、审查和指导 MCP 规范的演进，以及 MCP 项目的其他所有部分，例如文档，
* 阐明项目的连贯长期愿景，
* 以公平和透明的方式调解和解决有争议的问题，在可能的情况下寻求共识，同时在必要时做出果断选择，
* 任命或移除维护者，
* 以 MCP 的最佳利益为宗旨管理 MCP 项目。

核心维护者作为一个小组，有权通过多数票否决维护者做出的任何决策。核心维护者有权自行解决争议。核心维护者应公开阐明他们的决策制定。核心小组负责采用自己的决策程序。

核心维护者通常对所有 MCP 仓库拥有写入和管理员访问权限，但应使用与外部贡献者相同的贡献机制（通常是拉取请求）。基于安全考虑可以例外。

### 首席维护者 (BDFL)

MCP 有两位首席维护者：Justin Spahr-Summers 和 David Soria Parra。首席维护者可以否决核心维护者或维护者的任何决策。这种模型在开源社区中也常称为仁慈独裁者终身 (BDFL)。首席维护者应公开阐明他们的决策制定，并为他们的决策提供清晰理由。首席维护者是核心维护者小组的一部分。

首席维护者负责确认或移除核心维护者。

首席维护者尽可能成为 MCP 项目所有基础设施的管理员。这包括但不限于所有沟通渠道、GitHub 组织和仓库。

### 决策流程

核心维护者小组每两周开会讨论和投票提案，以及讨论任何需要的主题。如有需要，可以使用共享的 Discord 服务器讨论和投票较小的提案。

首席维护者、核心维护者和维护者小组应尝试每三到六个月面对面开会。

## 流程

核心和首席维护者负责模型上下文协议的所有方面，包括文档、问题、内容建议，以及 [MCP 项目](https://github.com/modelcontextprotocol) 下的所有其他部分。维护者负责 MCP 项目的各自领域文档、问题和内容建议，但鼓励参与 MCP 项目的总体维护。维护者、核心维护者和首席维护者应使用与外部贡献者相同的贡献流程，而不是直接更改仓库。这提供了意图洞察和讨论机会。

### 工作组和兴趣小组

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

兴趣小组负责识别和阐明 MCP 应解决的问题，主要通过促进社区内的开放讨论。相比之下，工作组专注于通过协作生产可交付成果来开发具体解决方案，例如 SEP 或规范的社区所有实现。虽然兴趣小组的输入可以帮助证明形成工作组的合理性，但这不是严格要求。同样，在提交 SEP 或其他社区提案时，鼓励但不强制来自兴趣小组或工作组的贡献。

我们强烈鼓励所有对特定 SEP 感兴趣的贡献者首先在兴趣小组内协作。这种协作过程有助于确保提议的 SEP 与协议需求一致，并为其采用者指明正确方向。

#### 治理原则

所有小组在遵守这些核心原则的同时自我治理：

1. 明确的贡献和决策制定流程
2. 开放沟通和透明决策

两者都必须：

* 记录他们的贡献流程
* 维护透明沟通
* 公开做出决策（小组必须发布会议记录和提案）

没有指定流程的项目和工作组默认为：

* 通过 GitHub 拉取请求和问题进行贡献
* 官方 [MCP 贡献者 Discord](/community/communication#discord) 中的公共频道

#### 维护职责

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

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

### 规范项目

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

对规范的提议变更必须以书面形式提出，首先是提案摘要，概述它试图解决的**问题**，提出**解决方案**、**替代方案**、**考虑因素、结果**和**风险**。[SEP 指南](/community/sep-guidelines) 概述了 SEP 的预期结构信息。SEP 应在[规范仓库](https://github.com/modelcontextprotocol/specification)中作为问题创建，并标有标签 `proposal, sep`。

所有提案必须有来自 MCP 指导小组（维护者、核心维护者或首席核心维护者）的**赞助者**。赞助者负责确保提案积极开发，满足提案质量标准，并负责在核心维护者会议中提出和讨论它。维护者和核心维护者小组应定期审查没有赞助者的开放提案。六个月内未找到赞助者的提案自动被拒绝。

一旦提案有赞助者，它们被分配给赞助者并标有 `draft`。

## 沟通

### 核心维护者会议

核心维护者小组每两周开会讨论提案和项目。提案记录应公开。核心维护者小组将努力每 3-6 个月面对面开会。

### 公共聊天

MCP 项目维护一个带有兴趣小组开放聊天的[公共 Discord 服务器](/community/communication#discord)。MCP 项目可能为某些沟通拥有私人频道。

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

### 原则

* 模块维护者小组的成员资格基于功绩给予**个人**，在他们通过贡献、审查和讨论展示了其工作领域的强大专业知识后，并与整体 MCP 方向一致。
* 对于**维护者**小组的成员资格，个人必须展示与整体 MCP 原则的强大和持续一致性。
* 模块维护者或核心维护者没有任期限制
* 如果他们长期不积极参与，轻度标准将工作组或子项目维护移至"名誉"状态。每个维护者小组可以为其领域定义适当的不活跃期。
* 成员资格是针对个人的，而不是公司。

### 提名和移除

* 核心维护者负责添加和移除维护者。他们将考虑现有维护者的意见。
* 首席维护者负责添加和移除核心维护者。

#### 提名流程

如果维护者（或核心/首席维护者）希望为核心/首席维护者的考虑提出提名，他们应遵循以下流程：

1. 收集提名的证据。这通常以被考虑维护的仓库上合并的 PR 历史形式出现。
2. 在相关小组的维护者之间讨论他们是否会支持批准提名。
3. DM 社区版主或核心维护者，在 Discord 中创建一个私人频道，格式为 `nomination-{name}-{group}`。添加所有核心维护者、首席维护者和相关小组的共同维护者。
4. 为被提名者提供上下文。见下文了解在此处包含的内容建议。
5. 创建 Discord 民意调查，并要求核心/首席维护者对提名投票是/否。鼓励但不要求达成共识。
6. 在核心/首席维护者讨论和/或投票后，如果提名有利，相关有权限更新 GitHub 和 Discord 角色的成员将提名人添加到适当小组。提名者应在相关 Discord 频道中宣布新的维护身份。
7. 临时 Discord 频道将在一周后删除。

在提名某人时与核心维护者分享的信息类型建议：

* GitHub 个人资料链接、LinkedIn 个人资料链接、Discord 用户名
* 您正在为哪些小组提名该人担任维护者
* 该小组是否同意此人应提升为维护者
* 迄今为止他们的贡献描述（包括最重要贡献的链接）
* 未来预期贡献的描述（例如：他们是否渴望成为维护者？他们是否有能力这样做？）
* 关于该人的其他上下文（例如：当前雇主、参与 MCP 的动机）
* 您认为可能与提名相关的任何其他内容

## 当前核心维护者

* Inna Harper
* Basil Hosmer
* Paul Carleton
* Nick Cooper
* Nick Aldridge
* Che Liu
* Den Delimarsky

## 当前维护者和工作组

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