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

# SEP-2085: 治理继任与修订流程

> 治理继任与修订流程

<div className="flex items-center gap-2 mb-4">
  <Badge color="green" shape="pill">
    最终版
  </Badge>

  <Badge color="gray" shape="pill">
    流程
  </Badge>
</div>

| 字段       | 值                                                                               |
| -------- | ------------------------------------------------------------------------------- |
| **SEP**  | 2085                                                                            |
| **标题**   | 治理继任与修订流程                                                                       |
| **状态**   | 最终版                                                                             |
| **类型**   | 流程                                                                              |
| **创建日期** | 2025-12-05                                                                      |
| **作者**   | David Soria Parra ([@dsp-ant](https://github.com/dsp-ant))                      |
| **发起人**  | David Soria Parra ([@dsp-ant](https://github.com/dsp-ant))                      |
| **PR**   | [#2085](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2085) |

***

## 摘要

本 SEP 确立了模型上下文协议 (MCP) 项目中首席维护者继任和治理修订的正式流程。它定义了首席维护者离职时的领导层过渡清晰流程，并确立了提议和批准治理结构本身变更的要求。

## 动机

当前的 MCP 治理结构定义了角色和职责，但缺乏两种关键场景的明确流程：

1. **领导层继任**：治理文档将 Justin Spahr-Summers 和 David Soria Parra 标识为首席维护者 (BDFL)，但未指定如果其中一人或两人离职会发生什么。如果没有定义的继任流程，意外的离职可能会导致项目领导层和决策权的不确定性。

2. **治理演进**：随着 MCP 项目的增长和社区的演变，治理结构可能需要适应。目前，没有定义治理文档本身如何修订的流程，这可能导致在没有适当社区输入的情况下进行临时变更，或使进行此类变更的权限不明确。

在项目领导层稳定时建立这些流程，可确保连续性并为未来场景提供清晰指导。

## 规范

以下章节应添加到 MCP 治理文档中。

### 继任

如果首席维护者因任何原因离职，继任流程在其书面通知时开始，或者如果无法提供通知，则由剩余的首席维护者或核心维护者确定该首席维护者无法继续任职时开始。

如果剩下一名或多名首席维护者，他们应任命继任者（如果有多人则通过多数投票），剩余的首席维护者将继续治理直到任命继任者。

如果没有首席维护者剩余，核心维护者应在 30 天内通过多数投票任命继任者，项目在任命新首席维护者之前由核心维护者的三分之二投票运作。

### 修订

对此治理结构的修订只能由首席维护者提议。任何提议的修订必须获得所有核心维护者的三分之二 (2/3) 多数批准才能生效。

修订提案应：

1. 以书面形式提交，并清楚说明提议变更的理由
2. 包含描述对现有治理条款修改的具体措辞
3. 允许至少五 (5) 天的评论期后再进行投票
4. 由核心维护者通过记录投票决定

## 理由

### 继任流程设计

继任流程的设计考虑了以下原则：

* **连续性**：剩余的首席维护者可以继续运作并任命继任者，而不中断项目治理。
* **后备权限**：如果所有首席维护者离职，核心维护者拥有选择新领导层的明确权限，防止治理真空。
* **限时流程**：30 天的要求确保继任迅速发生，同时允许足够的审议时间。
* **过渡期超级多数治理**：过渡期间的三分之二投票确保重大决策在过渡期间获得广泛支持。

### 修订流程设计

修订流程平衡了稳定性与适应性：

* **首席维护者提案权**：将提案权限限制为首席维护者，可防止因频繁的修订提案而导致治理变动，同时确保对项目投入最深的人能够推动必要的变更。
* **核心维护者批准**：要求三分之二核心维护者批准，确保修订获得积极治理项目人员的广泛支持。
* **评论期**：至少五天的评论期允许受影响方在投票前审查并提供意见。
* **记录投票**：投票的透明度确保了问责制，并提供了治理决策的历史记录。

### 考虑的替代方案

**选举继任**：曾考虑公开选举流程，但被拒绝，因为在关键过渡期间可能具有破坏性且缓慢。当前的提案允许快速继任，同时通过现有的维护者结构保持检查。

**任何维护者修订**：曾考虑允许任何维护者提议修订，但这可能导致治理不稳定。当前的方法平衡了稳定性与演进能力。

**更长的评论期**：曾考虑更长的评论期（例如 30 天），但对于已经拥有定期双周核心维护者会议的项目来说被认为过长。五天允许至少一个会议周期，同时能够及时决策。

## 向后兼容性

本 SEP 添加了新流程而未修改现有治理结构。不存在向后兼容性问题。

## 安全影响

本 SEP 没有直接的安全影响。然而，清晰的继任流程通过确保项目的持续负责任管理（包括安全相关决策）间接支持安全。

## 参考实现

一旦被接受，本 SEP 将通过把继任和修订章节添加到 `docs/community/governance.mdx` 来实现。新章节将插入到"首席维护者 (BDFL)"章节之后和"决策流程"章节之前。

一旦可用，实施这些变更的草案拉取请求将链接在此处。