挑战：没有第二个吉多

没有其他任何人拥有吉多·范罗苏姆独一无二的技能组合。这样的人需要具备领导项目成功的技术、沟通和组织经验。具体来说，这个人需要

• 制定并阐明项目的一致性长期愿景；
• 拥有对运行时、标准库和更广泛的第三方库环境的深入技术理解；
• 以所有相关方都认可的方式协商和解决有争议的问题；
• 拥有空闲时间并拥有持续参与数年的精力。

风险：终身恶意独裁者

如果我们找到的人没有像我们第一位独裁者那样适合这个职位怎么办？在某些情况下，这可能导致严重的后果。

由于缺乏技术深度、“接近”的选举、不一致的愿景、处理冲突或倦怠的能力差等，独裁者可能无法获得足够的信任。鉴于独裁者以某种特定方式做出的有争议的决定，缺乏足够信任的独裁者可能会导致项目内部分裂。

独裁者制度会导致游说集中在一个人身上。除非这个人由于财富、健康和稳定的生活状况而免受影响，否则这会带来恶意行为者在幕后操纵项目的风险。

最后，来自社区特定部分的独裁者可能会更加重视该特定用户群体的需求和利益，从而疏远其他人。

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

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

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

风险：模糊提案带来的温暖模糊感

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

如果在模型提案中没有命名 BDFL，我们就不是在谈论一个具体的模型。我们可以避免提出和回答难题。我们可以想象我们最好的情况，一个我们希望担任该角色的候选人。

不为 BDFL 命名也使社区模型处于不公平的劣势。我们已经了解了核心开发者团队的优缺点。它不是柏拉图式的理想，也不是没有摩擦的完美球体。事实上，我们预计会出现相当多的摩擦和缺陷。

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

结论 虽然这是我们的历史，但在没有吉多的情况下，此模型不利于该语言的未来发展。

风险：稀释和混乱

此模型偏向于一个由三到五人组成的小团体。这样一来，它与独裁者模型共享大部分批评，并且被放大了。拥有三个人而不是一个人处于权力地位，稀释了责任，同时仍然存在游说、信任不足或疏远社区部分成员的高风险。

风险：内部冲突

此外，让多个人共享治理责任为内部冲突、项目长期愿景不一致提供了充足的机会，并使成员所需的持续时间参与度成倍增加（如果他们由于其他时间承诺而无法“达到法定人数”，则不是法定人数）。

就像无摩擦的球形 BDFL 一样，拒绝委员会的想法，而没有考虑如果该委员会由你认为不适合该角色的三个人组成，它对你来说将如何运作。想象一下，如果我有两个朋友。

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

结论 此模型与独裁者具有相似的风险，只是更糟糕。

核心团队

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

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

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

专家

Python 开发人员指南列出了许多感兴趣的领域以及被认为是该领域专家的核心开发人员的姓名。专家或专家小组承担以下责任

• 及时响应分类到给定感兴趣领域的错误跟踪器上的问题；
• 及时审查被识别为属于给定感兴趣领域的拉取请求；
• 概述给定感兴趣领域发展中的连贯设计。

核心开发人员可以随意分配和取消分配自己到给定感兴趣的领域。必须让列出在给定感兴趣领域的现有专家了解此更改，并且他们必须一致同意。

如果给定感兴趣的领域列出了多个专家，则它们在核心团队中形成一个子团队。他们共同负责给定感兴趣的领域。

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

主持人

有一群人，其中一些不是核心开发人员，负责确保官方沟通渠道上的讨论遵守行为准则。他们针对违规行为采取行动。

PEP，增强版

PEP 流程在 PEP 1 中已有的信息基础上，增加了以下更改和说明。

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

非常有争议的 PEP

如果核心贡献者对某个特定的 PEP 感觉强烈反对，在 FCP 期间，他们可以通过投票提出否决该 PEP 的动议。投票细节在下面的“投票机制”中描述。

这应该作为最后的手段，因此这种情况很少发生。它会分裂核心团队，并且对所有相关人员来说都是一个压力很大的事件。但是，为 PEP 提交 FCP 的专家应该对是否可能出现否决投票的动议有一个很好的判断。在这种情况下，应注意避免过早提交 FCP。

对于相反的情况，即专家希望拒绝一个 PEP 但其他人希望接受它，则没有补救措施。这确保了相关专家对内容有最终决定权。如果您确实想要进行该更改，请想办法说服他们。

官方沟通渠道的版主首先要执行行为准则，以确保所有相关方之间进行健康的互动。执行可能会导致特定参与者被排除在进一步的讨论之外，从而被排除在决策过程之外。

重新审视延迟和拒绝的 PEP

如果 PEP 被推迟或拒绝，在再次尝试相同的想法之前，应首先联系相关专家。如果专家同意有充分的证据证明重新审视该想法是合理的，则可以打开一个编辑被推迟或拒绝的 PEP 的拉取请求。

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

提名新的核心开发者

负责人通过在官方沟通渠道上发布信息提名某人成为新的核心开发者。投票开始。

如果任何现有的核心开发者对提名人获得提交权限感到不舒服，他们最好在提名线程中解决这个问题。如果没有令人满意的解决方案，他们可以投反对票。

在实践中，提名某人为核心开发者通常会让其他人感到意外，因为这个人还没有成为核心开发者。换句话说，当候选人已经为其他人所熟知并足够信任时，就应该这样做。我们应该避免基于潜力的提名。

不信任投票

• 将核心开发者从核心团队中移除；
• 解散某个感兴趣领域的专家团队。

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

如果核心开发者通过投票被从核心团队中移除，他们将失去与项目互动的能力。移除他们发布错误跟踪器和 GitHub 上的帖子或仅在个案基础上缓和他们未来的行为，取决于版主的酌情决定。

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