摘要

本 PEP 提出了一种治理模型，尽可能减少程序、定义的术语和百分比。它也可以被称为无政府主义治理模型，但目前使用共享一词，因为无政府主义一词可能对某些受众有负面含义。

基本思想是，原则上所有决定都由整个社区投票决定，但在实践中仅由社区的一个子集投票决定。这是一个子集，因为尽管整个社区有权投票，但在实践中，始终只有一个小部分子集会对特定决定进行投票。投票由一个公正的委员会监督，委员会判断决定是否通过。该委员会的意图是，其决策不仅基于赞成票和反对票的比例，而且还基于投票总数、被投票决定的提案的严重性，以及可能包括的个人投票者及其投票方式。因此，该委员会负责确保每个单独的决定都由足够的多数票通过。

PEP 拒绝

PEP 8014 已于 2018 年 12 月 17 日星期一，根据PEP 8001 中描述的核心开发者投票被拒绝。

PEP 8016 及其描述的治理模型已被选中。

简介

共享治理模型试图确保所有决定都得到 Python 社区足够多数的支持，或者至少是可以接受的。

不幸的是，上一段中包含两个在一般情况下很难量化的术语：足够的多数和Python 社区。这是因为这两个术语在现实中取决于正在做出决定的具体情况。举个例子来说明这种困难：对于一个提出对某个 API 进行向后兼容更改的 PEP 来说，对最初有兴趣对该 PEP 进行投票的开发者来说，简单的多数可能就足够了。但对于一个具有更深远影响的更改，例如 Python3 到 Python4 的过渡，可能需要真正的多数，并且需要证明在用户群中至少有足够的支持。对于超越 Python 语言的更改，例如关于废除不包含语言的决定，就会变得非常模糊。

共享治理模型试图通过不在一般情况下定义足够的多数和Python 社区这两个术语，而提出一个机构，该机构将在具体情况下做出决定，从而回避这个问题。

该模型提议成立一个长老会，负责监督决策过程，并根据具体情况确定特定提案是否获得足够支持。每个单独的 PEP 都将进行投票，长老会将宣布投票结果是否足以在此特定情况下做出决定。

该模型仅涉及决策过程中传统上由 BDFL 承担的角色，而不涉及其他角色。

模型名称中的共享一词，是基于其历史上的用法，作为一种所有者共享并维护的共享资源。你应该参考的模型是，一群农民在一个温暖的夏夜在村庄的绿地上讨论关于未来的计划，然后进行投票，村里的长老宣布结果。然后宴会开始。

共享治理模型不同于大多数其他治理提案（可能除了 8012），因为它明确地将最高权力赋予整个社区。

基本原理

该模型的基本原理是，一个将所有内容都固定在水泥中的模型将产生意想不到的负面影响。例如，一个将投票权分配给 Python 提交者的治理模型可能会导致个人不被接受为提交者，因为新候选人所在的公司已经有很多提交者了。

另一个例子是，设定 PEP 接受的固定百分比可能会导致投票者之间的党派形成，而单个 PEP 也不再根据个人优点进行评判，而是根据党派立场进行评判（如果你支持我的 PEP，我就会支持你的 PEP）。

还有一个问题是，一人一票并不是像 Python 这样的东西的最佳模型。再举个例子：如果出现票数分裂（或投票结果非常接近于分裂），核心开发者 Guido van Rossum 的意见可能应该比核心开发者 Jack Jansen 的意见更有分量。试图在投票模型中正式化这一点将导致一个非常复杂的模型，无论如何，该模型在边界情况下都会出错。此处提出的模型将此类问题的决定留给（希望是明智的）长老会。

决策流程

所有重要决定都通过 PEP 流程进行。每个 PEP 都有一名负责它的人，这里称为作者，但这不一定是一个人，也不一定是实际编写文本的人。因此，对于作者，你也可以理解为推动者或守护者或类似的东西。

PEP 作者负责组织对 PEP 的投票。该投票是公开的，即投票者身份已知，结果对所有人公开。投票可以是简单的 +1/0/-1，但也可能扩展为 +2/-2，并附带一个非常简洁的解释，说明投票者为什么对该问题有强烈的感受。这种注释将作为对长老会的解释。投票者将标注其社区身份（核心开发者等）。

投票与讨论明显分开，使用明确定义的 Discourse 类别或标签、特殊邮件列表或类似的技术方法（例如网站 vote.python.org，人们必须登录才能自动添加其社区身份，并且可以确认其身份）。

PEP 作者向长老会提交 PEP 和投票结果。长老会考虑两件事

• PEP 的重要性及其影响，
• 可衡量的投票结果（多少人投票，哪些人投票，他们投了哪些票）。

他们对投票是否通过做出初步决定，并发布该决定。

如果决定是投票结果没有证明社区对该决定有足够的支持，那么作者有责任尝试获得更多支持，并在稍后的日期重新提交投票。或者，作者可以撤回提案。获得更多支持的期限是有限的，一个月似乎是合理的时间，如果在此期限后没有重新提交投票，则该提案被拒绝。

如果初步决定是投票结果确实证明了足够的支持，那么一个相当短的等待期将开始（大约几周）。在此期间，任何人都可以向长老会提出申诉，但只有以投票结果没有反映社区的足够多数为理由。等待期结束后，长老会宣布最终决定。PEP 要么被接受，要么（如果长老会被申诉所打动），将回到需要证明更多支持的状态。

长老会

长老会的意图是，他们共同能够判断特定投票结果是否维护了 Python 社区的意志。

长老会不是用一群拥有与 BDFL 相同权力的人来取代 BDFL：它不会提供关于 Python 方向的指导，它只是试图确保投票结果代表社区的意志。

长老会不像美国最高法院，最高法院拥有实际的决策权，长老会只监督投票过程，以确保社区在投票中得到体现。长老会也绝对不像西班牙宗教裁判所，因为恐惧、惊讶和冷酷的效率是我们不需要的东西（但使用可爱的猩红色礼服有一定的好处）。

长老会有点像荷兰的最高法院（不幸的是，在英语中通常被翻译为最高法院），他们判断过程和遵循的程序，只能将案件发回重新审判。

它也类似于许多国家（以不同的名称）拥有的选举委员会，它负责监督选举。

讨论

本 PEP 仅处理 BDFL 的其他角色，不包括投票过程。最重要的是，Python 的长期方向预计不会由长老委员会处理。这将由整个社区（或社区的个别成员，最有可能）来完成。

还有代表 Python 和 Python 社区面向外部世界的领袖或发言人的角色。同样，我认为这 *不是* 由长老委员会处理的角色，而是由其他人或机构处理。

请注意，此提议很可能比进步更倾向于保守主义。或者，至少，它导致停滞的危险大于它导致鲁莽地冲向未知领域的危险。因此：我们应该意识到，如果采用此模型，类似于 PEP 572 的 PEP 很不可能通过。

版权

此文档已置于公有领域。