Skip to main content

​
摘要

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

​
动机

当前的 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 一经可用即链接于此。