Guido van
Rossum最近宣布，他将从Python的“终身仁慈独裁者”（BDFL）角色中退出，这引起了一些惊讶，不过也不算很震惊，至少在核心开发人员社区中是这样的。在一些不太重要的功能点上，Van
Rossum几年来一直在传达某些变化。尽管也有最近的原因（如“PEP 572
问题”），这有点让人沮丧。与此同时，Python项目需要解决如何自治发展——然而Van
Rossum没有指定接班人，而是将社区治理问题留给了那些核心开发人员们。
Van
Rossum在过去的几年里有些筋疲力尽，其中至少有一部分原因是因为参与他所感兴趣的PEP的有争议讨论引起的。围绕PEP
572（“赋值表达式”）的讨论很可能是Python历史上妨碍Python发展的最严重问题。它涉及了多线程，同时在两个不同的邮件列表中（开始于python-ideas，一旦“就绪”，会被提交到python-dev），产生了两个独立的民意调查（大家都不倾向于增加该特性），同时，有时候这些讨论看起来似乎是无休止的争论。也许最令人恼火的是它的反复被提出；不管PEP的作者（最初是Chris
Angelico，在快要结束时Van Rossum和Tim Peters
也加入进来）多次与其他一些人不断的重复宣布反对，同样的想法仍然被一次又一次地被提出。很显然，许多人只是在情感上（有时是恶作剧的）对这个建议作出反馈：根本不看PEP内容或任何讨论，然后大声宣称他们的观点显然是唯一明智的。
Van
Rossum说他将作为常规核心开发人员继续“坚持一段时间”，但是他把上述问题留给社区，去决定项目治理。他似乎很好奇能看到什么进展：“那么，你们大家打算怎么办？创造民主？无政府主义？独裁？联邦？”正如他在辞职信中多次提到的，人们希望他能在未来一段时间内继续留在BDFL；仅仅因为PEP有争议的讨论而离开，甚至比简单的退休决定更令人伤心。在所有的良好祝愿中，对Van
Rossum声明的许多回复，都表达了一种意思，也是Python社区里经常说的：卷起袖子开始工作。
新治理
Van
Rossum呼吁治理的主要领域有两个：如何确定PEP进展以及如何添加新核心开发人员。后者似乎已经确定，就是新核心开发人员加入必须基于现有核心开发者的投票决定。他们也是唯一被允许发送邮件到核心委员会邮件列表的人，这里是Van
Rossum发布辞职声明的地方，大概是为了避免涉及回复数百条信息——几乎毫无疑问都是积极的和感激的，尽管肯定也会有一些不怀好意的信息。
对于PEP和其他主要的有关Python的决策，Christian
Heimes建议将三人制或五人制（三人制或五人制的管理机构）作为决策机构。Victor
Stinner认为，可以参考PHP的一些做法，核心开发者具有投票权。不过，Stinner的解决方案并不特别受欢迎。Brett
Cannon这样说：
“对我来说，我认为Guido作为BDFL，为我们提供了设计/品味的一致性。通过投票方式由委员会进行的设计决策一点也不吸引我，因为这样很容易导致偏好的转变，并且没有语言统一设计的良好凝聚力，尤其是感觉总会有主观的选择(最终必须有人选择小屋的颜色)。所有人，包括我，也指出，通过让Guido来决策，我们对社区应该如何表现也保持一贯的观点，这也是一种资产。我不喜欢Victor的提议。”
三人组（或N人组用于一些小的决定、临时的N人组）的想法似乎已经有一些吸引力，尽管谁会参与其中，他们将服务多久时间，以及其他细节仍在讨论中。还有一个不可避免的问题是，这个组织的名称是什么，已经提出了各种各样的想法，其中一些名称比其他的显得更真诚一些。但是，正如Raymond
Hettinger所说，还没到最后关头：
“我建议我们先转换到其他问题，暂时推迟主要的更改——这将给我们时间来消化已经正在运行的更改，这将给其他实现更多的机会来赶上这些更改（我们已经忽视它们的改变有一段时间了）。”
大部分讨论的是PEP决策过程，以及将如何改变。在Van
Rossum辞职之前，他是PEPS的最终仲裁者，除非他把权力交给BDFL代表。许多人认为“Python长老理事会”（PCOE）或“设计组织者”（两个比较流行的理事机构名称）的作用在很大程度上是找到合适的人授权，为给定的PEP做决策。如果没有达成一致意见，该组织也将成为最后的决定机构。
但是还有一个问题，就是人们要在这样的机构里任职多久。有些人呼吁“终身”的任命，并且可以随时离开，而其他人希望看到人们按照时间间隔轮流任职。但是，在确定之前（可能通过PEP或一系列的PEP），必须确定机构的职责。Heimes提出了三个职能：
首先向领域专家们授予职责权利
其次是提供一致性和信任
最后在争议无休止的情况下给予最终结论
然而，如果主要的作用是授权，那么它就不需要终身制工作。正如Doug Hellmann所说：
“如果决策的主要途径是授权，除非仲裁员是绝对必要的，从每个人都能很好理解的讨论历史以及在没有达成共识（注意“共识”而不是“一致同意”）的情况下保持现状的意愿两个角度来看，长期一致性和稳定性不如找到一个人可以长期服务于N人组机构更重要。”
“建立系统来支持和鼓励人员更替，就像我们对待发布经理一样，降低了被指定人员同意服务时所付出的努力门槛。总体来说，经过了很多的讨论，上述这一点在Python社区和普通开源社区中，似乎成为一个重要特征。”
如何作出决定和沟通也有了说法。有人提议要求全体委员一致投票，但这可能过于严格。Barry Warsaw建议不要公布成员的个人投票，只公布结果，但是Larry Hastings和其他人对此有不同的看法：
“
一般来说，我喜欢在治理上更加透明，作为这个机构所管理的社区的成员，我更喜欢对决策过程和思考有更多的洞察。我不认为PCOE为了之间的相互支持和支持机构的决定而统一口径，或者暗地里工作。
阳光，而不是黑暗
Hastings和其他人将PCOE视为像美国最高法院类似的一个团体，只有当有争议无法解决时，才会做出决定。但是Ukasz Langa想知道为什么三个成员的人数如此受欢迎：
“如此少的成员让我看到一连串的问题，比如某个组织只需要雇用三个成员中的两个就可以接管Python的设计过程（始终对第三个成员进行投票）。如果成员中有一人弃权，3人组就会有很高的关联可能性，诸如此类。”
宪法
他还关心“设计组织者”的作用将如何确定：“Python需要一个‘宪法’，将规定委员会是什么以及它如何运作。”许多人称该文件为“PEP
2”，但鉴于它将如何被接受的条件完全悬而未决。Langa 提出了一个建议，但是可能不受Van
Rossum的欢迎：“理想情况下，Guido会接受PEP，但我不确定他是否愿意。如果情况确实如此，那么如何做到这一点，使该文件得到所有委员会的普遍认可？”
很多人都认同上述观点；很显然，几乎普遍都是希望Van
Rossum仍将发挥积极作用，甚至在某些PEP上担任BDFL代表。Carol Willing可能总结了很多人对Van
Rossum参与的看法：“大多数时候，我希望Guido做任何能震撼他世界的事情。”Cannon有一个具体的想法，如果Van
Rossum愿意：“在我的理想场景中，人们编写提出PEP治理模式，Guido选择一个，使之成为PEP 2。”
对于Van Rossum来说，他确实短暂地参与了这个进程，以帮助阐明他在决定治理方面的作用：“我仍然在这里，但我想退出辩论，退出决策循环。我还是PSF[Python Software Fund ]的主席。但这不是PSF决定的。你们都做得很好。”
所以某种“神性干预”很可能是不可能的。核心开发人员需要自己解决这个问题。Willing建议在确定治理模式时有两条指导原则：“如果演进的内容包含Python
Zen[PEP
20]和‘我来是为了语言，留下来是为了社区’，那么我相信Python在技术上会受益。”事实上，Python社区是一个强大的社区，这是Van
Rossum在过去28年左右领导社区的遗产。
作为制定治理计划过程的一部分，Nathaniel
Smith正在组织一个信息化的PEP来调查其他开源项目的治理。我们的想法是看看是否有可以用于Python的部件或者零件。另一项努力，其中一些甚至早于Van
Rossum辞职，是找出一个更好的方式来讨论PEP并试图就它们达成共识。Hettinger提出了一种可能性：
“对于更大的决定（并且没有很多即将做出的决定），我有一些关于如何改进讨论的建议，以便利害关系方在结果中拥有更加平等的发言权，并且使得讨论能够更加有效率（跟上长期的发展以及活动中的线程需要很多时间）。”
“本质上，这个想法是由所有参与者编辑的wiki／FAQ。它将包括关键的例子，支持和反对的论点，以及反驳，这些可以被收集到一个当前状态的会话中。这与当前的PEP线程有些不同，因为当前PEP作者主导了会话，而其他人的意见可能太容易被忽视。（这个想法是模仿加州立法分析选民指南，该指南概括了提案，并且有来自支持者和反对者的声明和反驳）。”
Neil Schemenauer用经济术语说：
“也许这可以看作是一种经济问题。张贴到PEP讨论线程的成本与每个人阅读该帖子的成本是多少？或者，评论的价值是什么？每个人阅读的代价是什么？”
“用目前的讨论方法，成本往往是不成比例的。你有成百上千的人在读这个帖子。所以阅读的成本很高。发表一个半生不熟的评论太容易了。用新的主题线启动一个新帖子线程太容易了。”
一旦他们完成在python-ideas邮件列表中“自由自在的西部”上发起的讨论后，他建议为PEP讨论建立一个单独的邮件列表。PEP讨论列表将有一些基本规则，试图最大限度地利用每个人的时间。完全参与者与Python用户或开发人员的成本不成比例，而这些用户或开发人员只是想发泄，这很有可能在导致Van
Rossum辞职事件中扮演了重要角色。
显然，尘埃落定和具体计划的制定需要一些时间，但是人们会感觉到Python社区已经准备好了——即使不是完全愿意——自治。不过，这个过程将在开放环境中进行，这对于经历类似甚至不同的转换的其他项目可能是有帮助的。在开源世界里，项目可以相互学习，当然，从技术的角度来看，还可以在治理和社区等领域学习。
我们再把本网站的“谢谢你Guido”加在这里。我们的网站依赖于Python，已经有16年甚至更长时间了。Van
Rossum用他的努力为世界做出了伟大的贡献，这不可能改变，即使所有这些都已经过去了。在很多方面，Python社区反映了它的BDFL；它通常令人愉快的语气和对每个人的友好程度是许多其他项目应该尝试模仿的。
英文原文：https://lwn.net/SubscriberLink/759756/931b0f4617723184/
译者：接口模式
