Django意欲改革管理机构和模式

发布时间:2018年11月20日。归档于:Django, Python。

如果你不是那种密切关注Django开发内部细节的人，那么你可能不知道有一份提议草案要彻底改变该项目的管理。GitHub和邮件列表上一直在讨论这个问题，但是今天我想花点时间来解释一下这个提议是做什么的，以及它试图解决哪些问题。就让我们一探究竟吧。

Django怎么了?

Django这个web框架做得非常好。它是一个稳定的、流行的软件。Django开源项目目前还不错，但是有一些问题需要解决。最大的问题是大多数大型开源项目迟早都会遇到的一个问题:难以招募和留住足够多的活跃贡献者。

一些大型的开源项目通过有效地获得企业赞助来规避这一问题:借由依赖这些开源软件的公司员工帮忙维护项目以确保持续发展。我想Django早期也是以这种方式生存，因为它是由其开发公司开源的，而且几个关键的贡献者后来在那里工作了一段时间，但是这并没有真正成为一个长期的计划。

这意味着Django完全依靠满腔热情的贡献者，他们中的大多数人并没有从此项目中获得报酬，而这些贡献者人数也越来越少了。近几年，随着Django项目越来越成熟,一些简单的Bug修复或小功能添加的需求已经越来越少了，而这些操作本来是吸纳新贡献者的一个很好的途径，这也就是说，Django的成功也是造成其贡献者短缺的原因之一。

这并不意味着Django现在的状况很糟糕，但它确实意味着Django在未来可能会很糟糕;一段时间以来，该项目未能以足够的速度引入新的提交者，来取代那些变得不那么活跃甚至完全不活跃的提交者，而且这种情况完全是不可持续的。

除此之外，Django在从整个用户群中吸引贡献者方面做得并不好。Django本身在全世界很受欢迎，这归功于多种多样的免费研讨会和课程，这些研讨会和课程是一种为发展中国家萌芽期程序员进行的关于软件开发的一般介绍，以及频繁地对许多决定开始技术生涯的妇女介绍编程。然而,目前活跃提交者的名单一点也体现不出这点,只有少数妇女曾经是Django的重要技术贡献者，更不用说提交者了，而且目前没有一名妇女是活跃的，并且目前活跃的提交者名单似乎完全来自欧洲、北美和澳大利亚。

这是一个强烈的信号，表明该项目没有很好地将使用Django的开发人员转变为从事于Django的开发人员。从整个Django用户群体中获取贡献是此项目长期生存的必要条件，也是避免单一文化团队容易遇到的问题的关键。

有些事情需要改变，这就是为什么这个提议会存在，以及为什么改革/重组Django核心团队在过去几年里一直是各种与Django有关的邮件列表上的一个常见主题;我正在描述的这个提议是试图把讨论推进到实际行动。这不是灵丹妙药，也不会在一夜之间解决Django的所有问题。但是我相信这是解决这些问题的第一步。

一点背景知识

要理解所提议的内容，了解Django中角色和管理的一些历史是很有用的，因为Django一直运行到现在。

起初，Adrian、Jacob、Simon和Wilson为他们的雇主(堪萨斯州一家名为Lawrence Journal-World of Lawrence的报纸)开发了一些工具，使快速构建web应用程序变得容易。他们获准在BSD许可证下将其开源，并将其命名为“Django”，并于2005年中旬向公众公开。随着社区贡献的蜂拥而来,他们将提交权利授予了更多的一些人,对第一任管理结构进行了合并:Adrian和Jacob担任“BDFLs”(仁慈的独裁者,借鉴了Python语言中Guido van Rossum的头衔),但是他们大多情况是在其他任何方式无法做出决定时进行拍板。还有一些提交者可以随意添加或修改Django中的代码，并帮助分类、审查和合并来自更广泛社区的贡献代码。

2014年，Adrian和Jacob宣布他们打算从BDFL卸任。这并没有显著改变Django的管理，因为很少需要他们行使决策权，但是作为一种死锁避免的措施，他们被一个新的小组取代:Django技术委员会。技术委员会由提交者组成，由提交者选出，每个发布周期选举一次。技术委员会填补了BDFLs过去所扮演的角色，充当了最终的裁判和决策者，并拥有向Django添加新提交者的否决权(该权利从未行使过)。

Journal-World最初拥有Django，因为它是第一个公开发布版本代码的商标和版权的持有者(Django的贡献者拥有自己的贡献代码，并同意许可将这些贡献代码在Django中使用; Journal-World只拥有原始代码)。但是对于一个开源项目来说，被盈利性公司拥有是一个尴尬的局面，所以在2008年，Journal-World帮助成立了一个501(c)(3)非营利组织——Django软件基金会——它可以作为Django知识产权资产的管理人和所有者。DSF还参与筹款，并利用这些资金在世界各地赞助与Django有关的活动，以及促进Django本身的发展。

最终，DSF在2014年确立了“Django Fellow”的地位。Django Fellows是资助Django开源项目日常维护和运行的承包商。他们对票据进行分类，审查推送请求（原文：pull requests），制作和公布发布包，在邮件列表上回答问题，以及处理项目中的许多其他重要事情。

出于披露和背景的考虑，我了解这一切，并提出了改变它的提议，因为我在Django项目和更广泛的社区中担任过很多职务。其中包括:从2007年开始，我拥有一个提交位;我已经在技术委员会进行了五次版本发布;过去三年我一直是Django软件基金会的董事会成员。

关于本提议

现在我终于可以解释提议的内容了。请记住，这是一个高度概括，省略了许多细节。如果你想要完整的提议和所有的细节，请阅读DEP草案。

从理论上讲，Django开源项目的当前管理结构是任何人都可以提出更改或提交补丁，但是关于Django的所有决策都是由提交者(“Django核心”)做出的，技术委员会是他们的后盾。提交者基本上可以对Django进行任何他们喜欢的更改，并且只对彼此和技术委员会负责。

实际上，很少有提交者真正使用他们的提交位。决策是通过协商一致做出的，包括提交者和未提交者在Django开发人员列表上的输入，对Django主仓库的大多数实际提交都是由会员(原文:Fellows)做出的。即使是拥有自己的提交位的人员,他们有权直接将更改推入Django，通常也会使用推送请求(原文:pull request)和征求讨论，并且许多提交者(大约有40人)是不活跃的。

与此同时，作为Django提交者(“核心开发人员”、“Django核心”或你喜欢怎么称呼它)仍然被视为一个高声望的头衔，提交者会受到来自更广泛的社区的尊重。由于实际的日常维护工作很少依赖于具有某种特殊权力或威望的提交者，这是一个问题,特别是因为它似乎会对潜在的贡献者造成一种印象：他们不是“足够好”来匹配这些八面威风的泰坦尼克号人(请注意讽刺:我跟八面威风一点也不挨边)。

因此，我建议解散“Django核心”，撤销几乎所有提交位。反正它们大多都没用过!

为了代替提交者，两个新的角色形成了——合并者和发布者——它们分别将推送请求（原文：pull requests）合并到Django以及包/发布版本中。但这些并不是全能的决策者，而是官僚角色;没有一个人有权自己补写代码并将其推入Django。最初设置的合并者相当于当前设置的Fellows，而类似的事情也将发生在发布者身上。

管理将完全公开地在Django开发者邮件列表中进行，来代替(在理论上)由提交者进行决策，任何想要真诚参与的人都可以自由地这样做，包括投票支持或反对任何有争议的更改。这已经基本上就是事情运行的方式。

作为最终的裁判层，技术委员会将被保留，并拥有一些它目前没有的额外决策权(主要是在必要时参与合并者/发布者角色的选择，并确认Django的新版本已经准备好进行发布)。与现在相比，技术委员会的选举频率将会降低(可能只在每个主要发行版系列选举一次，而不是每个次要发行版选举一次)，但是考虑到技术委员会的人员流动率已经很低，这似乎不是一个问题。对技术委员会以及Django其他管理层的选举投票,将对Django开发人员名单上诚信参与的开发者保持开放,而DSF将在技术委员会选举中扮演一个中立的管理员角色(有权力拒绝不诚信的选民;当然，担任技术委员会候选人的DSF董事会成员将被要求回避与这些选举有关的事宜)。

目标和依据

我希望，消除像上帝一样的“提交者”和普通贡献者之间的区别将有助于项目对任何人的贡献都更加开放，特别是通过将代码提交给Django的行为变成一项官僚任务，并使Django开发人员邮件列表中的所有声音都保持平等。这本身并不能解决招募足够多新贡献者的问题，也不能解决他们之间缺乏多样性的问题，但我认为这将使我们有更好的基础来解决这些问题。

保留技术委员会作为解决僵局决定的后盾可能是必要的。给它一点比目前拥有的更大的权力,如发行的最终批准发布——并不理想,但是我认为这将有助于平息那些对本提议第一反应是“Django会陷入某种混乱的暴民统治中”的人们的恐惧。技术委员会的被选举资格目前要求被选举者是一个Django提交者;今后，它仍然需要对该框架作出有记录的历史贡献。

让DSF在技术委员会选举中发挥监督作用是一个很实际的问题。需要有人来做这件事，而DSF是最适合的一个中立的团体，尽管它很关心Django的长期生存(事实上，这是DSF存在的合法目的之一，正如其公司章程中所规定的那样)。赋予它广泛的权力来监控选民名册，可以防止恶意分子、塞选票者和其他不满分子(尽管我仍然担心他们)。

最后，我认为这将使对Django管理的正式描述更加符合项目的实际运行情况和过去几年中的运行情况，这种运行方式一直是很不错的。

接下来的步骤

还在制定中的完整细节在DEP仓库中的提议草案中(DEP是Python的PEP的Django等效版本)。我仍在收集反馈意见，并根据反馈意见对提议进行调整，但我希望提议能在下月之内得到合理的投票结果。

从此以后，要实现这一点，必须出现许多官僚主义:

Django核心团队必须对该提议进行投票。对Django开源项目组织和管理机构的改变需要五分之四的多数票才能通过。

Django技术委员会-----它对改变组织和管理具有绝对否决权- -必须审议这项提议，而不是否决它。

Django软件基金会必须考虑该提议，其董事会必须投票接受DSF在新的管理结构中的角色，并提供任何必要的资源。

最后，提议必须实施，包括关闭目前的django-core邮件列表和#django-core IRC通道;撤销一串提交位和其他权限;并建立新的管理流程。

当然，所有这些都需要时间。但我希望，到明年年中，Django能够在这种管理结构下运行，更好地解决剩余问题。

如果你收到了反馈，请随时在DEP仓库的推送请求中（原文：pull request）留下评论，或者私下与我联系。

英文原文：https://www.b-list.org/weblog/2018/nov/20/core/

译者：浣熊君( ･᷄৺･᷅ )