摘要

本 PEP 提议延续单一技术项目领导者模型，该模型被委婉地称为 Python 治理的“终身仁慈独裁者”（Benevolent Dictator For Life, BDFL）模型，在本 PEP 中今后将称为“仁慈裁决影响决策官”（Gracious Umpire Influencing Decisions Officer, GUIDO）。名称的变更反映了 GUIDO 作为 Python 语言决策过程最终仲裁者的视野扩大，需要与更广泛的开发社区协商，并认识到“终身”虽然可能是一种愿望，但不一定符合语言本身或 GUIDO 本身的最佳利益。

本 PEP 描述了

• 维持单一技术领导者模型的理由
• GUIDO 的选拔、选举、留任、罢免和继任过程；
• GUIDO 在 Python 语言演进过程中的角色；
• 任期长度；
• GUIDO 与就技术问题向 GUIDO 提供建议的 Pythonistas 委员会 (CoP) 的关系；
• CoP 的规模、选举和角色；
• 决策委托过程；
• PEP 流程的任何调整以适应新的治理模型；

本 PEP 不 指定新的 BDFL。如果此模型被采纳，它将与本 PEP 中描述的所有职位的名称一起，被编入 PEP 13。

PEP 驳回

PEP 8010 在 2018 年 12 月 17 日星期一被描述于 PEP 8001 中的核心开发者投票 否决。

取而代之的是 PEP 8016 及其描述的治理模型。

公开讨论点

在本 PEP 的参数中，在治理讨论过程中允许进行各种微调，例如 CoP 的确切规模、任期长度和服务时间，以及投票程序。在 PEP 准备好进行投票时，这些内容将得到明确。

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

如果随着模型的使用经验的积累，未来在指定 GUIDO 时，对这些参数进行微调，以提供更顺畅的治理过程，这是允许的，甚至可能是预期的。

为何需要单一技术领导者？

为什么选择这个模型而不是其他模型？这归结于“愿景”。“委员会设计”（Design by committee）有许多已知的缺点，导致语言会根据当时贡献者的各种兴趣来积累新功能。一句名言是“骆驼是委员会设计的马”。委员会设计的语言能否“协调一致”？它能否给人一种连贯、自洽的感觉，规则合乎情理且易于记忆？

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

灵活性

通过欠规范化，GUIDO 和 CoP 都获得了不同程度的灵活性。本 PEP 描述了冲突将如何解决，并期望所有参与者，包括核心开发者、社区成员和职员，始终以 Python 及其用户的最佳利益为重。PEP 假设相互尊重和最佳意图将始终带来共识，并且行为准则（Code of Conduct）管辖所有互动和讨论。

GUIDO 的角色

GUIDO 最重要的职责之一是为 Python 语言的演进提供一个跨越多个版本的、广泛的、连贯的愿景。当决策具有持久的影响和相互竞争的利益时，这一点尤其重要。例如，如果 C API 的向后不兼容更改导致 Python 性能提高 2 倍，不同社区成员可能会在辩论双方都提出令人信服的论点，并且可能无法达成明确的共识。任何选择都同样有效。在与 CoP 协商后，GUIDO 的愿景将指导最终决定。

GUIDO 是 PEP 和其他问题的最终决策者，包括任何特定更改是否值得 PEP。与今天一样，许多（甚至可能大多数）决策是通过在问题跟踪器、合并请求和讨论论坛上进行讨论和解决来处理的，通常有特定领域的专家提供输入或领导。在这些操作程序运行良好的情况下，它们可以保持不变。这也有助于减轻 CoP 和 GUIDO 的工作量，将最重要和最宏观的决策留给中央权威。

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

GUIDO 拥有完全的权力来终止无益的讨论、想法和提案，当其明确认为提案违背 Python 的长期愿景时。这样做是出于对变革倡导者的同情，但也是为了所有社区成员的健康和福祉着想。关于死胡同提案的恶意讨论对任何人都没有好处，GUIDO 可以通过命令终止它们。

总而言之：GUIDO 有权对任何主题（技术或非技术）做出最终裁决，但改变治理 PEP 本身除外。

权威来自社区

GUIDO 的权威最终属于社区。失去大多数社区信任的鲁莽 GUIDO 可以被罢免并重新进行投票。这是一个极其罕见且不太可能发生的事件。这是最坏情况的最充分的保障措施，因此不应轻易采取。GUIDO 不应因一个决定而被罢免，即使这个决定不受大多数 Python 开发者的青睐。罢免应保留给对 Python 语言或社区造成严重损害的行为。

Pythonistas 委员会（见下文）有责任发起不信任投票。

任期长度和任期限制

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，GUIDO 作者 PEP 的最终权威属于 CoP。

PEP 提议得到进一步增强，核心开发者必须始终被选为 PEP 牧羊人（PEP Shepherd）。这个人确保遵循适当的程序。牧羊人必须从核心开发者中选出。这意味着虽然任何人都可以成为 PEP 的作者，但所有 PEP 都必须获得至少一名核心开发者的支持。

版本历史

版本 2

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

版权

本文档已置于公共领域。