Model Context Protocol遵循正式的治理模式，以确保透明的决策与社区参与。该文档说明了项目的组织方式及决策机制。
技术治理
MCP项目采用分层结构，类似于Python、PyTorch等开源项目：
- 一个贡献者社群，他们提交问题、发起拉取请求，并为项目贡献力量。
- 一小群维护者负责推动MCP项目中的组件，例如SDK、文档以及其他内容。
- 贡献者和维护者由核心维护人员监督，他们推动项目的整体方向。
- 核心维护者中有两位主要核心维护者，他们是最终决策者。
- 维护者、核心维护者和主导核心维护者构成 MCP 指导小组。
所有维护者都应强烈认同MCP的设计理念。技术治理流程中的成员资格适用于个人，而非公司。也就是说，没有为特定公司保留席位，成员资格与个人而非雇佣该个人的公司相关联。这确保了维护者以协议本身及开源社区的最佳利益行事。
技术治理通过一个共享的Discord服务器进行，该服务器集合了所有维护者，核心维护者和主要维护者。每个维护者群体可以选择额外的沟通渠道，但所有决策及其支持性讨论必须记录并在Discord服务器上透明地提供。
维护者
维护人员负责MCP项目内的各个项目或技术工作组。这些通常是独立的代码库，如特定语言的SDK，但也可以扩展到代码库的子目录，例如MCP文档。维护人员可以采用自己的规则和流程来做决策。维护人员应独立为其相应项目做出决策，但必要时可以推迟或上报给核心维护团队。
代码质量:
- 通过以下方式强制执行编码标准和最佳实践：代码审查、代码规范检查，以及自动化测试
- 与社区贡献者进行周到且富有成效的互动，
- 维护并改进MCP项目中各自的领域，
- 支持modelcontextprotocol项目的相关文档、路线图及其他相关部分，
- 将社区的想法呈现给核心团队。
鼓励维护人员在需要时提议增加新的维护人员。维护人员的任命和移除只能由核心维护人员或首席核心维护人员在任何时候无需理由地进行。
维护者对其各自的代码库拥有写入和/或管理访问权限。
核心维护团队
核心维护者应深入理解 Model Context Protocol 及其规范，他们的职责包括：
- 设计、审视并指导MCP规范及所有其他MCP项目组件的演进（包括文档），
- 明确项目长期的整体愿景，
- 以公平透明的方式调解和解决争议问题，在可能的情况下寻求共识，并在必要时做出果断选择，
- 任命或移除维护人员，
- 以MCP的最佳利益为出发点，对MCP项目进行管理
核心维护者群体有权通过多数投票否决维护者的任何决策。核心维护者有权按其认为适当的方式解决争议。核心维护者应当公开阐述其决策过程。核心小组负责采用自己的决策程序。
核心维护者通常对所有 MCP 仓库拥有写入和管理权限，但应与外部贡献者使用相同的贡献机制（通常是拉取请求）。基于安全考虑可作例外处理。
核心维护负责人 (BDFL)
MCP有两位主要维护者：Justin Spahr-Summers和David Soria Parra。主要维护者可以否决核心维护者或维护者的任何决定。这种模式在开源社区中通常也被称为终身仁慈独裁者(BDFL)。主要维护者应当公开阐述他们的决策过程，并为其决定提供清晰的理据。主要维护者属于核心维护者群体。
首席维护人员负责确认或移除核心维护者。
主导维护者在所有MCP项目基础设施上都是管理员，只要条件允许。这包括但不限于所有沟通渠道、GitHub组织和代码仓库。
决策过程
核心维护团队每两周开会一次，讨论并对提案进行投票，同时讨论任何必要的议题。共享的Discord服务器可用于在需要时讨论和投票较小的提案。
首要维护者、核心维护者和维护者团队应尝试每三到六个月进行一次面对面会面。
核心和首席维护者负责Model Context Protocol的方方面面，包括文档管理、问题处理、内容建议以及MCP项目下的所有其他部分。维护者负责其负责的MCP项目领域内的文档、问题和内容建议，但鼓励参与MCP项目的总体维护工作。维护者、核心维护者和首席维护者应使用与外部贡献者相同的贡献流程，而不是直接对代码库进行修改。这有助于深入了解意图并为讨论提供机会。
项目与工作组
MCP 项目分为两个主要结构：项目和工作组。
项目是保存在专门仓库中的具体组件。这些包括规范、TypeScript SDK、Go SDK、检查器以及其他实现构件。
工作组是协作论坛，让感兴趣的各方讨论MCP的特定方面，而不需要维护代码库。这些工作组专注于传输协议、客户端实现及其他跨领域问题。
治理原则
所有项目和工作组在遵守以下核心原则的同时，均实行自我管理：
- 清晰的贡献和决策流程
- 开放沟通与透明的决策
两者都必须：
- 记录他们的贡献过程
- 保持透明沟通
- 公开做出决策（工作组必须发布会议记录和提案）
未指定流程的项目和工作组默认为：
维护职责
没有专门维护者的组件（例如文档）属于核心维护者的责任范围。这些组件遵循通过拉取请求提交的标准贡献指南，由维护者负责审核，并在进行任何重大更改时提升至核心维护者审查。
核心维护者和维护者被鼓励改进MCP项目的任何部分，无论是否有正式维护任务分配。
规范项目
规范增强提案 (SEP)
对规范的提议变更必须以书面版本形式提交，首先包含提案摘要，概述其试图解决的问题，提出解决方案、备选方案、注意事项，结果以及风险。SEP指南概述了SEP的预期结构信息。SEP应在规范存储库中以issue形式创建，并标记proposal, sep标签。
所有提案必须获得MCP指导小组（维护者、核心维护者或首席核心维护者）的赞助商支持。赞助商负责确保提案得到积极开发、符合提案质量标准，并负责在核心维护者会议中展示和讨论。维护者和核心维护者小组应定期审查无赞助商的公开提案。六个月内未找到赞助商的提案将自动被拒绝。
一旦提案获得赞助人，它们将被分配给赞助人并标记为draft。
核心维护者会议
核心维护团队每两周举行一次会议，讨论提案和项目。提案记录应当公开。核心维护团队将努力每3-6个月进行面对面会议。
公共聊天
MCP 项目维护一个 公共 Discord 服务器，并为兴趣小组提供开放的聊天空间。MCP 项目可能会为某些通讯设立专用频道。
提名、确认与移除维护人员
- 模块维护者群的会员资格在被授予个人时，基于功绩制，即他们在贡献、审查和讨论中展现出对工作领域的深刻专业知识，并与整体MCP方向保持一致。
- 要成为维护者小组的成员，个人必须展现出对整体MCP原则的强烈且持续的认同。
- 模块维护者或核心维护者没有任期限制
- 将工作小组或子项目维护人员转为“名誉”状态的轻松标准，即如果他们长时间未积极参与。每个维护者团队可以定义适合其领域的非活跃期限。
- 会员资格适用于个人，而非公司。
提名与移除
- 核心维护者负责添加和移除维护者。他们将考虑现有维护者的意见。
- 主要维护者负责添加和移除核心维护者。
提名流程
如果维护者（或核心/首席维护者）希望提出提名供核心/首席维护者考虑，他们应遵循以下流程：
- 提名的佐证材料收集。通常以拟考虑担任维护者的代码仓库中已合并PR的历史记录形式呈现。
- 与相关维护者讨论，确认他们是否支持批准该提名。
- 私信社区版主或核心维护者在Discord中创建一个私人频道，格式为
nomination-{name}-{group}。添加该相关工作组的所有核心维护者、主导维护者和共同维护者。
- 提供被提名人的背景信息。以下是一些建议内容。
- 创建一个Discord投票，并请核心/主导维护者对提名进行赞成/反对投票。鼓励但非必须达成共识。
- 经过核心/首席维护者讨论和/或投票后，若提名获得通过，具有更新GitHub和Discord角色权限的相关成员将把被提名人加入相应群组。提名者应在相关Discord频道中宣布新任维护者身份。
- 临时 Discord 频道将在一周后被删除。
提名他人时建议与核心维护者分享的信息类型：
- GitHub个人资料链接、LinkedIn个人资料链接、Discord用户名
- 你是为哪个/哪些组提名该人士担任维护者？
- 团体是否同意提升此人员为维护者身份
- 他们至今所做的贡献描述（包括最有实质贡献的链接）
- 对未来预期贡献的描述（例如：他们是否有意愿成为维护者？他们是否具备相应的能力？）
- 关于个体的其他背景信息（例如当前雇主，参与MCP的动机）
- 你认为任何其他可能与提名相关的需要考虑的信息
当前核心维护者
- 英娜·哈珀
- 巴兹尔·霍斯默
- 保罗·卡林顿
- 尼克·库珀
- 尼克·奥尔德里奇
- Che Liu
- 丹·德利马尔斯基
当前维护者与工作组
请参考维护者列表。 
