PEP 8014 – 共有治理模型
- 作者:
- Jack Jansen
- 状态:
- 已拒绝
- 类型:
- 信息性
- 主题:
- 治理
- 创建日期:
- 2018 年 9 月 16 日
摘要
本 PEP 提出了一个具有最少程序、定义术语和百分比的治理模型。它也可以称为无政府主义治理模型，但目前使用共有，因为“无政府主义”一词可能对某些受众产生负面影响。
基本思想是，原则上所有决定都由整个社区投票决定，但实际上只有社区的一部分人投票。一部分人，因为虽然整个社区都有投票权，但在实践中，只有一小部分人会就特定决定进行投票。投票由一个公正的委员会监督，该委员会判断决定是否通过。意图是，该委员会的决定不仅基于赞成票和反对票的比例，还基于投票总数、被投票提案的严重性以及可能的个别投票者及其投票方式。从而，该委员会负责确保每个个体决定都由足够多数的票数通过。
PEP 驳回
PEP 8014 在 2018 年 12 月 17 日星期一被核心开发者投票否决，详见 Python 治理投票结果（根据 PEP 8001 描述）。
取而代之的是 PEP 8016 及其描述的治理模型。
引言
共有治理模型试图确保所有决定都得到 Python 社区足够多数的认可，或者至少是可接受的。
不幸的是，上一段中有两个术语在一般情况下很难量化：“*足够多数*”和“*Python 社区*”。这是因为这两个术语实际上取决于正在决定的*具体*情况。举个例子说明这种困难：对于提议对某个 API 进行向后兼容更改的 PEP，足够多的核心开发者在首先对 PEP 进行投票是可能足够的。但对于影响更深远的更改，例如从 Python 3 过渡到 Python 4，可能需要真正的多数，并能证明用户群体中至少似乎有足够的支持。而对于超越 Python 语言本身的更改，例如关于废除不具包容性语言的决定，则变得非常模糊。
共有治理模型试图通过*不*在一般情况下定义“*足够多数*”和“*Python 社区*”的含义，而是提出一个将在*具体*情况下做出决定的机构来规避这个问题。
该模型提议创建一个*长老会*来监督决策过程，并根据具体情况确定特定提案是否获得足够支持。每次 PEP 都会进行投票，长老会将宣布投票结果是否足以通过*在此特定案例中的*决定。
该模型仅涵盖 BDFL 在决策过程中传统上扮演的角色，而不涉及其他角色。
模型名称中的“*共有*”（Commons）一词松散地基于其历史上作为供所有人使用、由所有人照料的共享资源的用法。您应该在此模型中想象的画面是，一群相当大的农民在夏日温暖的傍晚，在村庄绿地上讨论未来的某个计划，之后进行投票，村庄长老宣布结果。然后开始宴会。
共有治理模型与大多数其他治理提案（可能除了 8012）不同，因为它明确地将最高权力赋予整个社区。
基本原理
该模型的理由是，一个将一切都固定下来的模型将产生意想不到的负面副作用。例如，一个将投票权分配给 Python 提交者的治理模型，可能会导致某人因其公司已有太多来自同一公司的提交者而无法被接纳为提交者。
又例如，设定固定的 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 的发展方向提供指导，它只试图确保投票结果代表社区的意愿。
长老会*不像*美国最高法院，后者拥有实际的决策权；长老会仅监督投票过程，以确保投票能够代表社区。而长老会绝对*不像*西班牙宗教裁判所，因为我们不需要恐惧、惊喜和无情的效率（但使用可爱的猩红色服饰还是有些好处的）。
该委员会有点像荷兰的最高法院（Hoge Raad）（在英语中不幸经常被翻译为 Supreme Court），因为它会审判所遵循的进程和程序，并且只能将案件发回重新审理。
它也有些像许多国家（名称不同）拥有的*选举委员会*，负责监督选举。
议会运作
议会成员是志愿者，很可能在 Python 社区内担任其他角色（更不用说 Python 之外的生活）。这意味着成员的工作量应尽可能少。这也意味着，当个别议会成员以议会成员身份发言，以及以个人身份发言时，应该很清楚。我们还应该关心情感负担：不应让议会成员对 Python 邮件列表中随机的网络喷子做出的决定负责。
该提案试图通过两种方法来最小化工作量：
- 大部分实际工作由 PEP 作者和社区完成，长老会不组织投票和统计结果。
- 第一次初步决定的想法是，长老会的错误（最可能是误判 PEP 的影响有多大）不是致命的，因为社区有机会纠正这些错误。
从实际角度来看，这意味着初步决定可以由一部分委员会成员做出，依赖于社区的纠正。即使通过电子邮件，让七位辛勤工作的专业人士每两周聚在一起，可能有点强人所难。
最好使用一个特殊的电子邮件地址，或者一个只有长老会成员可以发帖的 Discourse 主题，来澄清个别长老何时代表委员会发言。这与教皇‘教皇无误’（Ex Cathedra）发言或仅以个人身份发言（在这种情况下他并非无误）有相似之处。长老们很可能是社区中受人尊敬的成员，如果他们因为在委员会中而无法表达他们对 PEP 的个人看法，那将是一个坏主意。
社区成员*与*长老会的讨论，即在申诉决定时，应在不同的论坛（Discourse 主题、邮件列表）进行。
长老会的决定应被视为整个委员会的决定，而不是个别成员的决定。在初步实施中，长老应该以自己的名字发帖（他们作为委员会成员发言的事实通过他们发帖的主题或特殊的徽章来表明）。如果事实证明长老们成为个人攻击的目标，我们应该重新审视这一点，并想出某种匿名方法。
自由限制
如果某个特定投票有真正的大多数（赞成或反对）核心团队成员（超过 50% + 1 的所有核心团队成员），该结果即通过。如果某个特定投票有真正的大多数（赞成或反对）PSF 投票成员（超过 50% + 1），该结果即通过。而且，为完整起见，如果前两个陈述都为真但结果相反，则核心团队成员获胜。
拥有此限制的主要原因是可以（尽管需要付出努力）做出决定，即使在任何特定时刻都没有正常的长老会。
议会组成
委员会不应该太大也不应该太小，大概在 5 到 10 名成员之间。没有理由固定这个数字。成员应该了解 Python 和 Python 社区，并愿意在*作为委员会一部分运作时*保持公正。委员会成员可以是核心开发者，但这并非强制要求。
社区中的每个人都应该感到由委员会代表，因此如果委员会是多元化的，那将是好的。
- 科学家和技术人员；
- 进步派和保守派（关于 Python 语言）；
- 不同文化背景、性别、年龄的人；
- 等等。
但是：这应该适用于整个委员会。不应将个别委员会成员视为代表特定利益群体。
议会成员资格
由于委员会的权力纯粹是程序性的，因此成员任期较长可能比较好。但是，定期重新任命委员会仍然是件好事。因此，建议让委员会在 PSF 的支持下运作，并接受年度信任投票。此投票是针对整个委员会的：那些投票反对委员会的人应该意识到，他们基本上是在说“Python 没有长老会比有你们这些家伙要好”。
委员会通常会吸收新长老，可能是因为某个人在委员会缺乏的 Python 社区（或语言）的特定领域拥有知识。每个人都可以向委员会推荐新长老（包括他们自己），但委员会可以忽略该建议。委员会成员应随时可以退休。个别委员会成员可以被其他委员会成员一致投票退休。
有一个紧急刹车程序可以罢免一个失灵的委员会。一个长老或 10 名核心开发者或 PSF 投票成员组成的团体可以要求立即对整个委员会进行重新任命投票（大概意图是委员会失去其授权）。如果此投票是由长老请求的，该个人立即失去其委员会职位，无论投票结果如何。如果投票是由社区成员请求的，并且委员会被重新任命，则此程序一年内不能再次启动。
如果没有正常运作的委员会（当前初始情况，或委员会在不信任投票后失去授权后），则必须选择一个初始委员会。通过正常的沟通渠道（Discourse、邮件列表），任何人（包括他们自己）都可以推荐成员。在提名人之间以及在整个社区进行讨论后，应该出现至少三名个人，他们要求进行初始投票以任命他们为长老会。此程序的意图是，当这样一群人出现并要求信任投票时，他们应该会期望获得压倒性的授权。
讨论
本 PEP 不处理 BDFL 的其他角色，仅处理投票过程。最重要的是，Python 的长期发展方向不应由长老会负责。这应该由整个社区（或更有可能是社区的个人成员）负责。
还有一个作为对外代表 Python 和 Python 社区的象征性人物或发言人的角色。同样，在我看来，这*不是*长老会应该承担的角色，而是应由其他人或机构来承担。
请注意，此提案很可能倾向于保守主义而非进步主义。或者，至少，它导致停滞的危险比它导致鲁莽地闯入未知领域的危险要大。所以：我们应该意识到，如果此模型到位，像PEP 572 – 赋值表达式这样的 PEP 可能会失败。
版权
本文档已置于公共领域。
来源：https://github.com/python/peps/blob/main/peps/pep-8014.rst