摘要

本 PEP 提出继续采用单一技术项目领导者模型，委婉地称为 Python 治理的“终身仁慈独裁者”（BDFL）模型，在本 PEP 中将改称为“指导决策的影响者”（GUIDO）。名称的更改反映了对 GUIDO 的扩展观点，即作为 Python 语言决策制定过程的最终仲裁者，并与更广泛的开发社区协商，以及认识到“终身”虽然可能是理想的，但不一定符合语言或 GUIDO 本身福祉的最大利益。

本 PEP 描述了

• 维持单一技术领导者模型的理由
• GUIDO 将如何被选择、选举、留任、召回和继承的过程；
• GUIDO 在 Python 语言演化过程中的角色；
• 任期长度；
• GUIDO 与 Pythonistas 委员会 (CoP) 的关系，该委员会就技术事项向 GUIDO 提供建议；
• CoP 的规模、选举和角色；
• 决策委托流程；
• 为适应新的治理模型而对 PEP 流程进行的任何更改；

本 PEP 没有指定新的 BDFL。如果采用此模型，它将与本 PEP 中描述的所有职员的姓名一起编入 PEP 13 中。

PEP 拒绝

PEP 8010 已被 核心开发者投票拒绝，如 PEP 8001 中所述，投票于 2018 年 12 月 17 日星期一进行。

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

开放讨论点

在治理讨论过程中，允许对本 PEP 的参数进行各种调整，例如 CoP 的确切规模、任期长度和投票程序。这些将在 PEP 准备投票时进行编纂。

本 PEP 中描述的投票程序和事件将默认为 PEP 8001 中指定的投票方法，尽管在撰写本文时该 PEP 仍在讨论中，因此可能会发生变化。

随着使用此模型获得经验，允许甚至可能预期在未来命名 GUIDO 时对这些参数进行调整，以提供更顺畅的治理流程。

为什么需要一位唯一的技术负责人？

为什么选择这个模型而不是其他模型？归根结底是“愿景”。委员会设计 有许多已知的缺点，导致语言根据当时贡献者的不同兴趣积累新功能。一句著名的格言是“骆驼是由委员会设计的马”。委员会设计的语言能否“保持一致”？它是否感觉像一种连贯、自洽的语言，其中规则有意义且易于记忆？

一位唯一的技术领导者比委员会能够更好地推广这种愿景，无论该委员会是规模小（例如 3 或 5 人）还是涵盖整个 Python 社区。每个参与者都会对“Python”是什么有自己的看法，当这些个人看法发生冲突时，这可能导致优柔寡断或不合逻辑的选择。CPython 应该快 3 倍，还是我们应该保留 C API？这是一个非常难以达成共识的问题，因为这两个选择都没有对错之分。但比做出错误的决定更糟糕的是，因为找不到共识而接受现状。

灵活性

通过欠规范，赋予 GUIDO 和 CoP 一定程度的灵活性。本 PEP 描述了如何解决冲突，但期望所有参与者，包括核心开发者、社区成员和职员，始终将 Python 及其用户的最大利益放在心上。本 PEP 假设相互尊重和最佳意图将始终导致共识，并且行为准则适用于所有互动和讨论。

GUIDO 的角色

GUIDO 最重要的角色之一是为 Python 语言的演变提供一个全面的、广泛的、连贯的愿景，涵盖多个版本。当决策具有持久影响和竞争性优势时，这一点尤其重要。例如，如果 C API 的向后不兼容更改导致 Python 性能提高 2 倍，那么不同的社区成员可能会在争论的双方都令人信服地进行辩护，并且可能不会出现明确的共识。两种选择都同样有效。在与 CoP 协商后，将是 GUIDO 的愿景指导最终决策。

GUIDO 是关于 PEP 和其他问题的最终决策权威，包括任何特定更改是否值得成为 PEP。与今天一样，许多——事实上也许大多数——决策都是通过问题跟踪器、合并请求和讨论论坛上的讨论和解决来处理的，通常由特定领域的专家提供意见或领导。在这种操作程序运行良好时，它可以保持不变。这也有助于减少 CoP 和 GUIDO 的工作量，仅将最重要的决策和最广泛的视野留给中央权威。

同样，如果认为特定更改需要 PEP，但 GUIDO 在与 CoP 协商后，确定了拥有完全信心做出最终决策的专家，则 GUIDO 可以为 PEP 指定代表。虽然 GUIDO 仍然是最终权威，但预计 GUIDO 不会破坏，实际上会支持代表作为 PEP 最终仲裁者的权威。

当提案显然违背 Python 的长期愿景时，GUIDO 有权关闭无益的讨论、想法和提案。这样做是为了体谅更改的支持者，但同时也要考虑到所有社区成员的健康和福祉。关于死胡同提案的有毒讨论对任何人都没有好处，并且可以通过法令终止。

概括地说：GUIDO 有权对任何主题（技术或非技术）做出最终裁决，但更改治理 PEP 本身除外。

权威来自社区

GUIDO 的权威最终来自社区。失去社区大多数成员信心的不法 GUIDO 可以被召回，并进行新的投票。这是一种极其罕见且不可能发生的事件。这是针对最坏情况的足够权宜之计，因此不应轻易采取。GUIDO 不应该因为一项决定而害怕被废黜，即使该决定没有得到大多数 Python 开发者的支持。召回应保留用于严重损害 Python 语言或社区的行为。

Pythonistas 委员会 (见下文) 负责发起对 GUIDO 的不信任投票。

任期和任期限制

GUIDO 将服务三个 Python 版本，考虑到当前的发布节奏，大约 4.5 年。如果 Python 的发布节奏发生变化，GUIDO 任期的长度应更改为 4.5 年，四舍五入到整个版本。如何进行舍入由潜在的发布节奏 PEP 决定。在此之后，将根据下面概述的程序进行新的选举。没有任期限制，因此 GUIDO 可以根据自己的意愿无限期地竞选连任。

我们期望 GUIDO 在整个任期内履行职责，但当然，生活会发生变故。如果 GUIDO 需要在任期结束前辞职，则将根据选择新 GUIDO 的流程填写空缺。但是，新 GUIDO 只能在原 GUIDO 任期的剩余时间内任职，届时将进行新的选举。辞职的 GUIDO 可以继续任职，直到他们的继任者被选中。

在过渡期间，CoP（见下文）可以执行 GUIDO 的职责，但他们也可能更愿意将实质性决策（例如技术 PEP 批准）留给即将上任的 GUIDO。

选择 GUIDO

当存在新 GUIDO 的空缺或 GUIDO 在正常情况下即将连任时，将触发选择流程。当选择流程由 GUIDO 辞职或在 GUIDO 常规任期结束前两个月触发时，新的选举流程开始。

在投票前三周，提名开放。候选人必须从当前的核心 Python 开发人员名单中选出。非核心开发者无资格担任 GUIDO。候选人可以自我提名，但所有提名必须获得附议。提名和附议以私有存储库中的合并请求的形式进行。

一旦候选人接受提名，他们可以使用相同的私有存储库发布简短的立场声明，也可以将其发布到提交者讨论论坛。也许我们甚至可以进行辩论！选举的这一阶段持续两周。

然后，核心开发者有三周时间进行投票，使用 PEP 8001 中描述的流程。

Pythonistas 委员会 (CoP)

协助 GUIDO 的是一个由当选的 Python 专家组成的小团队。他们在一个技术委员会成员团队中任职。他们提供见解并就 GUIDO 之前的选择进行讨论。咨询可以由双方发起。例如，如果 GUIDO 对任何特定选择仍然犹豫不决，与 CoP 的讨论可以帮助澄清剩余的问题，确定需要提出的正确问题，并深入了解对 GUIDO 可能不太熟悉的其他 Python 用户的影响。CoP 是 GUIDO 的信任顾问，预计双方将建立密切的工作关系。

CoP 由 3 名成员组成，从核心开发者中选出。他们的任期为 3 年，成员可以无限期地竞选连任。为了确保连续性，CoP 成员以轮换方式当选；每年，一名 CoP 成员将面临连任选举。

为了引导初始选举的交错，获得最多票数的 CoP 成员将任职 3 年，第二受欢迎的得票者将任职 2 年，获得最少票数的 CoP 成员最初将任职 1 年。

所有投票中的平局将通过 PEP 8001 中确定的程序解决。

提名和投票流程与 GUIDO 类似。有一个为期三周的提名期，允许自我提名并必须获得附议，然后是发布立场声明的时间段，最后是投票。

经 CoP 一致决定，可以开始对 GUIDO 进行不信任投票，从而触发该部分的程序。

不信任投票

如上所述，核心开发人员委员会（CoP）可以通过一致同意决定发起对指导委员会（GUIDO）的不信任投票。此流程不应轻易启动，但一旦开始，将触发最多两次投票。在这两种情况下，投票都按照PEP 8001中的程序进行，所有核心开发人员都可以参与不信任投票。

第一次投票是是否罢免现任GUIDO。如果大多数Python开发人员投票“不信任”，则GUIDO被罢免。然后进行第二次投票，根据最初选出该职位持有人的程序选出新的GUIDO。在没有GUIDO的这段时间里，重大决策将被搁置，但正常的Python操作当然可以继续。

日常运营

GUIDO并非所有（甚至大多数）决策都需要。Python开发人员已经有很多机会进行授权、承担责任和自主决策。问题跟踪器和拉取请求的作用与选择此治理模型之前完全相同。大多数关于错误修复和次要改进的讨论都可以像往常一样在这些论坛上进行。

PEP 考虑因素

GUIDO、CoP成员以及Python社区中的任何其他人都可以提出PEP。无论PEP的作者是谁，对候选PEP的处理方式都相同。

但是，如果GUIDO是PEP的作者，则应选择一位公正的PEP代表，并赋予其接受或拒绝PEP的权限。GUIDO应回避决策过程。在存在争议的PEP且未达成明确共识的情况下，CoP对GUIDO提出的PEP拥有最终决定权。

PEP提案进一步完善，要求始终选择一名核心开发人员作为PEP维护者。此人确保维护正确的程序。维护者必须从核心开发人员中选出。这意味着，虽然任何人都可以编写PEP，但所有PEP都必须至少获得一名核心开发人员的某种程度的支持。

版本历史

版本2

• 重命名为“技术领导者治理模型”
• “单一领导者” -> “单一技术领导者”
• 在PEP 8001获得批准之前，采用其投票程序是暂时的。
• 描述GUIDO辞职时会发生什么情况
• 罢免投票需要大多数核心开发人员的支持才能成功。

版权

本文档已置于公共领域。