IT思维

Guido van Rossum最近宣布，他决定放弃他在Python社区“仁慈大君”的称号，虽然这令人有些意外，但在核心开发社区却并没有太大的震惊。虽然最近的“PEP 572混乱”事件是不幸的，但 Van Rossum几年来一直在为Python暗暗的做着努力。 与此同时，该项目需要弄清楚如何管理自己前进 – Rossum没有任命继任者，并将治理问题留给了核心开发人员。

在过去的几年里，Rossum一直燃烧着他的热情，起码在一定程度上是因为他一直在为自己感兴趣的PEPs进行有争议的讨论。关于PEP 572(“赋值表达式”)的讨论很可能是Python历史上最糟糕的冒险。

它跨越了多个巨大的线程，在两个不同的邮件列表上，生成了两个独立的投票(poll)(这两个投票都不支持这个特性)，而且有时似乎是没完没了的。也许最让人恼火的是它的重复性;同样的想法被一次又一次地提出来，不管PEP的作者(最初是Chris Angelico，后来在快结束时Van Rossum和Tim Peters加入了进来)和其他人不断地反对他们的论点。很明显，许多人只是在感情上(有时是表面上)对这个建议做出反应:不读激励语或任何讨论，然后大声宣布他们的观点显然是唯一明智的。很明显，许多人只是在感情上(有时是表面上)对这个建议做出反应:不阅读PEPs或任何讨论，然后大声宣布他们的观点显然是唯一明智的。

Van Rossum说，作为一个普通的核心开发人员，他将会在“一段时间内”坚持下去，但他留给社区来决定未来项目的治理。他似乎很好奇会发生什么:“那你们都要做什么?”创建一个民主吗?无政府状态?一个独裁政权?联盟?”正如许多人在辞职信中指出的那样，人们希望他在今后一段时间内继续担任“仁慈大君”;如果离开只是因为有争议的激励讨论，而不是简单的退休决定，那还是挺令人难过的。在所有的祝福之中，许多对Van Rossum声明的回复中都提到了Python社区人经常说的一句话:卷起袖子开始工作。

新的治理

Van Rossum呼吁进行治理的主要领域有两个:如何确定PEPs以及如何添加新的核心开发人员。后者似乎已经根据现有核心开发人员的投票决定好了。他们是唯一被允许发布到核心提交者邮件列表的人，这也是Van Rossum辞职的一方面，大概是为了避免费力地浏览数百条信息——几乎所有信息都是怀揣感激之心的，尽管肯定也会有一些是不好言论。

对于PEP和任何其他主要语言决定，Christian Heimes建议triumvirate(三人管理)或quintumvirate(五人管理)作为统治机构。 Victor Stinner认为应该考虑核心开发人员对功能提案进行投票的PHP流程。 不过，Stinner的解决方案并不是特别受欢迎。 Brett Cannon这样说：

对于我来说，我认为Guido为我们作为“仁慈大君”所提供的一个关键资产就是设计/品味的一致性。设计由委员会通过投票来决定并不吸引我,太容易导致偏好的变化，并且没有很好的凝聚力和语言的整体设计,特别是考虑到总是会有主观的选择。包括我在内的人们也指出，应该让Guido敬仰你，我们对社区的行为有非常一致的看法，这也是一种资产。

triumvirate(或一个小的、奇数N的N-virate)的想法似乎得到了一些支持，尽管“谁将加入”、“他们将服务多久”以及其他细节仍在讨论中。还有一个不可避免的问题是，这个群体的名字可能是什么?人们提出了各种各样的想法。但是，正如Raymond Hettinger所说，这件事情没有这么着急:

就目前而言,我建议我们转向低齿轮(low gear)以及推迟主要语言改变的时间,这将给我们时间来消化这些变化，给其他实施策略更多的机会来赶上进度。

讨论的大部分内容是PEP决策过程以及它将如何改变。在他辞职之前， Van Rossum 是PEPs的最后仲裁者，除非他将自己的权力委托给了另一位“仁慈大君”。许多人认为，“Python长老理事会”(PCOE)或“设计专员”(治理机构的两个比较流行的名称)的作用主要是找到合适的人选，以便在给定的PEP上进行决策。如果不能就一项决定达成协商一致意见，该小组也将是最后的决定机构。

但也存在人们在这样一个机构服务多久的问题。 有些人要求“终生”任命，因为他们明白人们可以在任何时候辞职，而其他人则希望随着时间的推移这些职位能轮换出来。然而，在此之前必须确定（可能通过PEP或一组竞争的PEP）该组的作用。 Heimes提出了三个功能：。

首先，将主要责任委派给领域专家。

其次，提供一致性和信任。

最后，在有争议的bike shedding事件中给出最后的结论。

但是，如果主要作用是委托，则不需要将其作为终身工作。 正如Doug Hellmann所说：

如果决策的主要方法是委托(除非绝对必要的仲裁者),那么长期的一致性和稳定性不会因为找到个人而在N-virate上服务很长时间，因为这项工作的完成是需要对评论有很好的理解以及有意愿在没有达成共识的情况下保持现状。

就像我们与发布经理所做的那样，构建系统以支持和鼓励人员更替，降低了当某人同意服务时的工作量。考虑到在Python社区和开放源代码中有很多关于倦怠的讨论，这似乎是一个重要的特性。

如何制定和沟通决策也是一个问题。 有人建议要求机构一致投票，但这可能过于严格。 Barry Warsaw建议不要公布成员的个人投票，而只是公布结果，但Larry Hastings和其他人的意见不同：

我更喜欢在治理方面提高透明度，作为受本机构管理的社区成员，我更倾向于更多地了解流程和进入决策的思路。 我不认为PCOE要求作为一个统一的秘密工作，应该让他们相互支持，并支持机构的决定。

Hastings和其他人认为PCOE类似于美国最高法院 – 这个机构只有在存在无法以任何其他方式解决的争议时才作出决定。 但是ŁukaszLanga想知道为什么有三个成员如此受欢迎：

对于triumvirate我看到了一些问题，比如一个公司只雇佣了三个成员中的两个就能接管Python的设计过程(持续地对第三个成员进行投票)。如果其中一名成员弃权，也有很大的可能产生关联等等。

“宪法”

他还担心如何确定设计管理员的角色：“Python需要一个‘宪法’，它将编纂委员会的内容及其运作方式”。许多人将该文档称为“PEP 2”，但在这种情况下如何接受该文档完全是未知数。Langa提出了一个可能不被Van Rossum接受的建议：“理想的情况是Guido会接受PEP，但我不确定他是否愿意接受。”如果确实如此，那么该如何做才能使该文件得到所有提交者的普遍接受呢?

很明显的，许多人都认同这种观点，几乎所有人都希望Van Rossum仍将担任一个积极的角色——也许甚至是作为一些PEPs上的“仁慈大君”。 Carol Willing可能总结了许多关于Van Rossum参与的观点：“我大多希望Guido做任何撼动他的世界的事情”。 如果Van Rossum愿意，Cannon有一个具体的想法：“在我的理想情景中，人们写PEPs提出治理模型，Guido选择一个，使其成为PEP 2。”

在这方面， Van Rossum确实短暂地插入了这个话题，试图阐明他在决定治理方面的角色：“我仍然在这里，但我希望退出辩论，退出决策圈。我还是PSF （Python软件基金会）的董事长。但这不是由PSF决定的。你们都做得很好了。”

因此，某种类型的“神圣干涉”很可能并不存在。核心开发人员需要自己解决这个问题。他表示，在确定治理模式时，有两种指导原则：“如果发展的内容包含Python之禅 （Zen of Python，PEP 20）和‘我为语言而来，为社区而留下’，我相信这种语言将从技术上受益。”实际上，Python社区是一个强大的社区，这证明了Van Rossum在过去28年里的领导能力。

作为制定治理计划过程的一部分，Nathaniel Smith正在组织一个信息化的PEP来调查其他开源项目的治理。我们的想法是看看是否有可用于Python的部件和零件。另一些努力甚至早于Van Rossum的辞职，就是找出一种更好的方式来讨论PEP，并试图达成共识。Hettinger提议了一种可能性：

对于更大的决策（并没有很多），我对如何改进讨论有一些建议，以便有关各方能够在结果中拥有更平等的发言权，从而使讨论更具时间效率。

基本上，这个想法是让所有参与者都可以编辑wiki/faq。它将包括关键的例子、赞成和反对的论据，以及可以收集到当前对话的rebuttal。这与当前的PEP过程有些不同，因为目前是PEP作者主导了对话，而其他人很容易被淹没。（这一想法模仿了加州立法分析师选民指南，该指南总结了各项提案，并有支持者和反对者的陈述和反驳）。

Neil Schemenauer用经济学术语来表述：

也许这可以被视为一种经济问题。发布到PEP讨论thread的成本与阅读该帖子的每个人的成本是分别多少？或者，评论的价值是什么，每个人阅读它的代价是什么?

使用目前的讨论方式，成本往往不成比例。有成百上千的人在阅读帖子，所以成本很高。而发表一个不成熟的评论太容易了。用新的主题线开一个新的thread太容易了。

他建议，一旦他们在python-ideas邮件列表中的“free-wheeling wild west”上完成了运行，就应该单独列出一个邮件列表，以便进行PEP discussion。PEP-discussion列表中有一些基本规则，目的是最大限度地利用每个人的时间。充分投入的参与者与Python用户或开发人员之间的不成比例的成本可能是导致Van Rossum由于倦怠而辞职的主要原因。

显然，事件尘埃落定和制定具体计划需要一段时间，但人们会觉得Python社区已做好准备——即使不是完全愿意——追求自治（self-governance）。不过，这一过程将在公开场合发挥作用，这可能会对其他经历类似甚至不同的过渡的项目有所帮助。在开源的世界中，项目可以从技术的角度互相学习，当然也治理和社区等领域相互学习。

我们每个人都应该（与其他人一起）感谢Guido，否则就是不负责任的表现。我们的网站依赖于Python，并且已经运行了16年或甚至更久。 Van Rossum 用他的努力为世界做出了伟大的贡献——即使在这一切都已过去之后，他的努力似乎也不太可能改变。在许多方面，Python社区是它的“仁慈大君”的反映；它令人愉快的基调和对每个人的友好是其他项目应该效仿的。