SEP-2085：治理继任与修订程序

社区译文；来源： MCP 29affa6b

摘要

本 SEP 为 Model Context Protocol 项目建立正式的首席维护者继任程序和治理修订程序。它定义首席维护者离任时领导层交接的明确流程，并规定提出和批准治理结构本身变更的要求。

动机

当前 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）”一节之后、“决策流程”一节之前。

接受后，将在此处链接一份实现这些变更的 pull request 草案。