提到 Debian 这个名字，人们总会联想到这个 Linux 发行版，但其实 Debian 项目远不止于此。它是一个正在进行的民主性的项目管理实验。Debian 的流程（process）可能确实导致了很多公开争议，但我们不应该忘记这样一个事实，即这些流程使得一个庞大的社区在没有企业管理人员监督的情况下几十年如一日地维护、开发了一个复杂的发行版。不过，工作流程还是可以改进的。Russ Allbery 最近提出的 一项建议 给大家描述了未来的一个可能性，其中介绍了痛点在哪里，以及什么可以做得更好。

Debian 中的决策

在很大程度上，Debian 把决定权交给了它的各位开发者。开发者的软件包就是他们的城堡，一般来说他们都可以按照他们认为合适的方式来进行管理。这种自由，在某种程度上受到了 Debian 章程（consitution）和详尽的 Debian 原则手册（policy manual）的限制，这些都是为了确保开发者和他们创建的软件包都能共存并且和睦相处。大多数时候，这个工作流程是有效的，这个项目大部分情况下都能正常提供版本发布，用户也很高兴。

然而，偶尔也需要一些干预。项目为这种情况下提供了两个处理机制，分别是技术委员会（Technical Committee）和一般决议（general resolution）。技术委员会有权对技术相关的政策做出决定，在最极端的情况下，如果开发者的行为被判定为对发行版具有很大的破坏性，那么委员会可以推翻 Debian 开发者的决定。一般决议流程则可以通过项目成员的投票来改变或推翻技术委员会（或其他人）的决定、制定新的政策、或者修改章程。

投票是主要的一个高于个人开发者的决策的机制。这在自由软件社区中并不罕见。许多项目都是通过普通会员或某种当选成员（通常也是通过投票当选）代表的投票来做出决定。不过，Debian 在决定其成员投票的方式上几乎是独一无二的。Debian 开发者不是简单地提供一个选项列表，而是自己创造所有这些选项，通常会有大量的选项，而且经常会引入许多相关讨论。选票的创造，这是 Debian 决议工作的一个重要部分。最后的投票结果仅仅统计最后的得分。

这个过程的目的是希望能创造出尽可能反映整个项目意愿的结果。Debian 的投票方式允许一张选票中包含许多差异不大的选项，从而不用担心投票被分流而导致一个相对不受欢迎的选项最终获胜。这种选票的优势是创造了一种投票方式，使得开发者可以投票给他们想要的方案，而不是仅仅投票反对最坏的情况。

但有时，这个过程并没有像许多人希望的那样顺利。在采用 systemd 之前经历的漫长而痛苦的讨论中，技术委员会对于发起投票就进行了长时间的争论。当委员会主席 Bdale Garbee 要求立即对简化过的投票 进行表决时，讨论才告一段落。这次表决也导致了结果分歧，最终由 Garbee 的决定票来解决。决定是做出了，但人们对这个决定的产生方式感到很不满意。

类似的问题在 2019 年的 另一场 systemd 辩论 中也出现过，当时采用的是一般决议程序。那时候 Debian 项目负责人 Sam Hartman 在一些开发者准备好他们的投票方案之前，就要求尽快对决议 进行投票，这让一些参与者感到很不满意。有人试图拒绝这个提前投票，但没有成功，于是对七个选项的投票就正常完成了。一些开发者认为这个过程又一次被滥用了，也对整个项目造成了损害。

争取改进流程

Allbery 建议来改变这一流程从而避免再出现类似结果。对于技术委员会来说，新的流程将允许任一位成员要求对一项公开决议进行表决，并立即开始投票。但是，如果有任一位其他成员在 24 小时内对投票提出反对，那么这次投票将被取消。如果这条规则在 systemd 的争论期间就已经存在的话，那么就不会产生让决议匆忙作出的投票了。不过另一个改动是，投票需要在这个决议首次被提出的两周后开始，如果到那时还没有人能成功地发起投票，则自动开始投票。这样一来，以 systemd 这个案例为例，就不会拖得太久来发起表决了。

对于一般决议的表决场景，实际投票前的讨论期长度是由项目负责人决定的。在这次流程改动提议中，这一点没有变化，但新的规则是将这个时期的时长限制在两到三周。对选票的任何实质性修改（例如增加新的选项）将会使得讨论期至少再增加一周，但这个时长仍然不能超过最长期限。如果讨论期能继续延长的时长少于 24 小时了，就不能再进行这类实质性修改了。项目负责人有权将讨论期缩短或延长一周，但缩短讨论期的情况下也必须要确保能至少还有 48 小时的时间。

针对这两种情况下的改动，目的显然是为了给决议的投票时间能给出一个相对比较确定的回答。在这两种情况下，讨论时间都有了一个上限，来确保讨论可以及时结束，但也准备了一些机制来防止在有关各方没有合理的时间来准备他们的投票方案就被迫进行投票。如果这些改动被原样采纳了，那么有争议的问题都应该能得到相对快速的解决，也就会更少出现参与者感觉自己被其他人利用流程来控制的情况。

我们可以把这些规则调整看作是对 Debian 决策过程中偶尔出现混乱的这种社区问题的一个技术方面的解决尝试。Allbery 是这样 描述他的动机 的：

我希望大家不要忽视拥有一个明确的程序的好处，即使事先指定一个流程会让人感觉吹毛求疵、受到限制，也别忘了它的好处。我在 Debian 的多次激烈辩论中，以及在其他类似的管理决策方面和在线社区争议中得到经验是，有良好的、明确的、事先商定好的流程，恰恰能为人们创造了足够的空间，使他们即使在强烈反对别人的意见时也能保持和蔼和配合。

此外，他说，如果人们在这个过程中不觉得自己被人欺负了，那么他就会更容易接受一个不符合他意愿的决策。

这些改动的早期版本 引起了相当多的讨论，但几乎没有什么反对意见或实质性的改变。也许最大的争论点是 有人建议 技术委员会内如果僵持住了就应该自动触发一个一般性决议流程来做出决定，而不是依靠委员会主席的决定性投票。不过，最后的共识似乎是，这样的规定会增加复杂性，而且好处不大，所以似乎不会改成这样。

在回应第二次发布的版本时，Timo Röhling 建议 要固定讨论期的长度，基本上不要给修改期限的机会。Röhling 说，这就会最大限度地减少那些企图利用规则的做法，使得后续流程对开发者来说更有确定性。Allbery 对这一观点表示了一定的赞同，但也表示有点灵活性可以帮助项目来及时处理更紧急的问题。除非其他人对这个讨论期时长限制提出反对意见，否则该提案似乎不太会修改这一点。

看起来有相当多的人支持 Allbery 的提议，但在这种情况下，“相当多” 可能还是不够的。这类似一项宪法改革，也就意味着需要进行一般性决议投票（根据之前的规则），而且决议必须以 3:1 的超级多数通过。Allbery 不希望匆忙提出一般性决议的要求，而是希望等到他觉得有很大可能性能获得超级多数支持之后再发起，因此他请求所有那些不支持现有提案的人解释一下原因。对第二版提案的回应很少，这也许是一个迹象，说明 Debian 项目确实已经准备好要做出这些改变了。

（题图：wallhere）