挑战：再没有第二个 Guido 了

没有其他人能拥有 Guido van Rossum 那样独特的技能组合。这样的人需要具备成功领导项目所需的技术、沟通和组织经验。具体来说，这个人需要：

• 为项目设定并清晰阐述一个统一的长期愿景；
• 对运行时、标准库以及更广泛的第三方库背景拥有深入的技术理解；
• 以所有相关方都能接受的方式协商和解决有争议的问题；
• 有空闲时间并拥有精力，能够持续多年参与。

风险：恶意的终身独裁者

如果我们找了一个不如第一任独裁者那样适合该职位的人，会怎么样？在某些情况下，这可能会导致严重的后果。

独裁者可能因为技术深度不足、“不分伯仲”的选举、不一致的愿景、处理冲突能力差或倦怠等原因，而得不到足够的信任。给定独裁者以特定方式做出的有争议的决定，一个缺乏信任的独裁者可能会导致项目分裂。

独裁者的设置会吸引针对单一人物的游说。除非这个人由于财富、健康和稳定的生活状况而对操纵免疫，否则这会带来被幕后恶意行为者操纵项目的风险。

最后，来自社区某个特定部分的独裁者可能会将更多权重放在该特定用户群体的需求和利益上，从而疏远其他人。

观察：我们实际上并不需要独裁者

独裁者模型的讽刺之处在于它需要选举。更好的是，我们需要选举来决定使用哪种治理模型。

如果我们已经能够通过社区流程解决这两个棘手的问题，为什么不将它用于所有后续决策呢？

风险：模糊提案带来的虚假满足感

最后一点值得一提的是，当提出 BDFL 模型时，很容易通过不提及 BDFL 的 *身份* 来绕过上述批评。这样，充满希望的读者可以将他们最好的期望和愿望投射到抽象的 BDFL 上，使这个想法看起来更有吸引力。这是一个错误。

在模型提案中不提及 BDFL 的姓名，我们就是在谈论一个不具体模型。我们可以避免提出和回答棘手的问题。我们可以想象我们最好的情况，一个可以胜任这个角色的人选。

省略 BDFL 的姓名也使社区模型处于不公平的劣势。我们已经知道我们的核心开发者群体的优点、缺点和不足。它不是柏拉图式的理想，不是没有摩擦的完美球体。事实上，我们预计会存在相当多的摩擦和不完善。

因此，为了公平地评估 BDFL 模型提案，亲爱的读者，您应该想象我们团队中最糟糕的人作为该 BDFL。一个具体的人。想象一下是我。

结论 虽然这是我们的历史，但在没有 Guido 的情况下，这个模型将不符合语言未来的最佳利益。

风险：稀释和混乱

该模型倾向于一个小群体，介于三到五人之间。这样，它会承担与独裁者模型的大部分批评，并且被放大。拥有不止一人，而是，比如说，三个人掌握权力，会稀释责任，同时仍然存在高风险的游说、信任不足或疏远部分社区。

风险：内部冲突

此外，多个人分担治理责任会为内部冲突、项目缺乏一致的长期愿景创造充分的机会，并会乘以其成员所需的持续时间（如果他们因为其他时间安排而无法“达到法定人数”，那就不是委员会了）。

就像对待一个没有摩擦的球形 BDFL 一样，在不考虑如果委员会由三个你认为不称职的人组成的情况下，拒绝委员会的想法。想象一下我有两个朋友。

最重要的是，就像对待独裁者一样，我们不需要委员会。当有了委员会时，我们已经成功举行了两次选举。为什么不继续投票呢？

结论 该模型具有与独裁者相似的风险，而且更糟。

核心团队

Python 项目由核心开发者团队开发。虽然成员资格由 GitHub 上“python”组织中的“Python core”团队的存在来决定，但贡献有多种形式：

• 提交更改到存储库；
• 审查他人的拉取请求；
• 在问题跟踪器上分类错误报告；
• 在官方 Python 通信渠道上讨论话题。

一些贡献者可能被认为是休眠的，换句话说，他们没有为 CPython 的最后两次发布做出贡献。任何休眠的贡献者都可以随时恢复贡献。

专家

Python 开发者指南列出了许多兴趣领域以及被认为是给定领域专家的核心开发者姓名。专家或专家子团队承担以下职责：

• 及时响应已分类到给定兴趣领域的错误跟踪器上的问题；
• 及时审查已识别为属于给定兴趣领域的拉取请求；
• 监督给定兴趣领域演进中的一致性设计。

核心开发者可以随时自行分配和取消分配自己到某个兴趣领域。必须让现有该兴趣领域的专家了解此更改，并且他们必须一致同意。

如果某个兴趣领域列出了多名专家，他们就组成了一个核心团队内的子团队。他们共同负责该兴趣领域。

核心开发者应避免同时担任过多兴趣领域的专家。本文档故意不指定最大数量，它只是表明过度劳累会导致倦怠，并且是项目在没有特定贡献者的情况下运作能力的风险。

主持人

有一群人，其中一些不是核心开发者，负责确保官方通信渠道上的讨论遵守《行为准则》。他们会处理违规行为。

PEP，增强版

PEP 流程在 PEP 1 的信息之上，通过以下更改和澄清进行增强：

• PEP 在最终决定做出之前不会被合并；在此之前，它们是 GitHub 上的开放拉取请求；
  • 为了方便审查，对正在审查的 PEP 的所有更改都应作为单独的提交进行，从而可以进行细粒度比较；
• 已提交的 PEP 需要标识兴趣领域和相关专家，作为对其做出最终决定的机构；
• 如果 PEP 作者是相关兴趣领域的专家之一，他们必须指定一个来自该兴趣领域之外的其他人来代替他们做出最终决定；
• PEP 作者负责使用官方通信渠道收集和整合对 PEP 的反馈，目标是建立共识；
• 所有社区成员都应能够提供反馈；
• 在某个时候，一位命名的专家会发布一个“总结评论”，概述讨论的当前状态，特别是主要的分歧点和权衡；同时，该专家会提议“最终评论期” (FCP) 的动议，以及一个处理方案，以
  • 接受；
  • 有条件接受；
  • 拒绝；或者
  • 推迟 PEP。
• 要进入 FCP，PEP 必须获得相关兴趣领域所有专家的签名批准；
• FCP 持续十四个日历日，以便利益相关者在做出决定前提出任何最终异议。

非常有争议的 PEP

如果核心开发者强烈反对某个 PEP，在 FCP 期间，他们可以提起动议，通过投票来否决它。投票细节将在下文“投票机制”中描述。

这应该是最后的手段，因此应该很少发生。它会分裂核心团队，并给所有相关人员带来压力。然而，为 PEP 申请 FCP 的专家应该对是否可能提起否决动议有很好的判断。在这种情况下，应小心避免过早申请 FCP。

对于相反的情况，即专家想否决 PEP 但其他人想接受它，没有追索权。这确保了相关专家对纳入的内容拥有最终决定权。如果你真的想要这个改变，想办法说服他们。

官方通信渠道的主持人首先要执行《行为准则》，以确保所有相关方之间的健康互动。执行措施可能导致某个参与者被排除在进一步的讨论之外，从而影响决策过程。

重新审视被推迟和否决的 PEP

如果 PEP 被推迟或否决，在再次尝试相同想法之前，应首先联系相关专家。如果专家同意有实质性证据支持重新审视该想法，可以打开一个编辑被推迟或否决的 PEP 的拉取请求。

事先未能获得适当的专家支持，很可能会导致被推迟或否决的 PEP 的拉取请求立即被拒绝。

提名新的核心开发者

一位推荐人通过在官方通信渠道上发布内容来提名一个人成为新的核心开发者。然后会开启投票。

如果任何现有核心开发者对被提名人获得提交权限感到不安，他们应优先在提名帖中解决此疑虑。如果没有令人满意的解决方案，他们可以投反对票。

实际上，提名一个人为核心开发者通常会让其他人感到惊讶，因为这个人还没有成为核心开发者。换句话说，这应该在候选人已经被其他人充分了解并信任时进行。我们应该避免基于 *潜力* 的提名。

不信任投票

• 将核心开发者从核心团队中移除；
• 解散特定兴趣领域的所有专家团队。

这些描述了一种核心开发者被强行从核心团队移除或专家团队被强行解散的情况。希望这些永远不会被用到，但它们被明确提及是为了说明一个功能失调的兴趣领域是如何被治愈的。

如果核心开发者被投票从核心团队中移除，他们将失去与项目互动的能力。主持人可以自行决定移除他们在错误跟踪器和 GitHub 上的发帖能力，或者仅根据具体情况管理他们未来的行为。

如果某个兴趣领域的专家团队被解散，其他核心开发者可以随时主动填补空缺。被解散的专家团队成员不能自行提名回归。