Possible changes to Debian's decision-making processes

The name Debian brings to mind a Linux distribution, but the Debian project is far more than that; it is an ongoing experiment in democratic project governance. Debian's processes can result in a lot of public squabbling; one should not lose track, though, of the fact that those processes have enabled a large community to maintain and grow a complex distribution for decades without the benefit of an overseeing corporate overlord. Processes can be improved, though; a recent proposal from Russ Allbery gives an interesting picture of where the pain points are and what can be made better.

Decision-making in Debian

To a great extent, Debian leaves decisions in the hands of its individual developers. A developer's package is their castle, and they can generally manage it as they see fit. That freedom is somewhat constrained by the Debian constitution and the extensive Debian policy manual, both of which are designed to ensure that both developers and the packages they create all get along. Most of the time, this process just works, the project generates (mostly) regular releases, and users are happy.

Occasionally, though, some sort of intervention is required; two of the mechanisms provided by the project for such cases are the Technical Committee and general resolutions. The Technical Committee is empowered to make decisions on technical policy and may, in extreme cases, override Debian developers if their actions are seen as sufficiently damaging to the distribution. General resolutions can, by way of a vote of the project membership, change or override decisions made by the Technical Committee (or others), set new policies, or amend the constitution.

Voting is a key part of decision-making at levels above the individual developer. This is not particularly unusual in the free-software community; many projects make decisions by a vote of either the general membership or some sort of elected (via a vote, usually) representatives. Debian is nearly unique, though, in the way it decides what its members will vote on. Rather than simply being presented with a list of choices, Debian developers create those choices themselves, often in great number, and often with a lot of associated discussion. The creation of the ballot is the important part of a Debian resolution; the vote at the end is just calculating the final score.

This process is designed to create outcomes that reflect, as well as possible, the will of the project as a whole. Debian's voting scheme allows a ballot to contain numerous options with small differences without fear of splitting the vote in a way that causes a relatively unpopular option to ultimately prevail. At its best, it creates ballots where developers can vote for the options they want rather than just voting against the worst case.

At times, though, this process has not worked as well as many would have liked. The long and painful discussion leading up to the adoption of systemd involved an extended and contentious discussion in the Technical Committee over the creation of the ballot. That discussion only came to an end when the committee chair, Bdale Garbee, cut it short by calling for an immediate vote on a simplified ballot — a vote leading to a split decision that was resolved by Garbee's casting vote. The decision was made, but nobody was particularly happy with how it came about.

A similar problem was seen in 2019 with yet another systemd debate, this one using the general-resolution process. Then Debian project leader Sam Hartman upset some participants by calling for a vote on the resolution as soon as he possibly could, before some developers felt that their ballot options were ready. An unsuccessful attempt to override this call was made, and the vote on the seven-choice ballot went forward. Once again, some developers felt that the process had been abused to the detriment of the project as a whole.

Toward an improved process

Allbery's proposal would change the process in ways intended to avoid this kind of outcome. For the Technical Committee, the new process would allow any member to call for a vote on an open resolution, with the vote beginning immediately. If, however, any other member objects to the vote within 24 hours, the vote will be canceled. Had this rule been in place during the systemd deliberations, the vote that brought things to an end would not have happened in the way it did. Another change, though, says that voting begins two weeks after a resolution is first proposed; voting starts automatically if nobody has successfully called for a vote by that point. So, in the systemd case, the ballot-creation process would not have dragged out for so long.

For votes on general resolutions, the length of the discussion period prior to the actual vote is determined by the project leader. That is still true with the proposed changes, but the new rules would set the length of that period to be between two and three weeks. Any substantive changes to the ballot (the addition of new option, for example) will force the discussion period to stay open for at least another week, except that this period still cannot exceed the maximum. Those changes cannot be made if the discussion period cannot be extended for at least 24 hours. The project leader has the power to either shorten or lengthen the discussion period by a week, but any shortening of the discussion period must still leave it open for at least 48 hours.

The purpose of these changes in both cases is apparently to give a relatively deterministic answer to the question of when a resolution will be voted on. In both cases, an upper bound is placed on the discussion time to ensure that things come to a timely close, but there are also mechanisms to prevent the calling of a vote before the parties involved have a chance to prepare their ballot options. If these changes are adopted, and if they work as intended, contentious issues should be resolved relatively quickly with fewer participants feeling that they have been outmaneuvered by procedural tricks.

It is possible to see these rule tweaks as a sort of attempt to apply a technical solution to the social problem of Debian's sometimes-messy decision-making processes. Allbery described his motivation this way:

I would encourage everyone to not discount the merits of having a clear process, even if it feels nit-picky and constraining to specify one in advance. My experience in multiple heated debates in Debian, and in similar problems in other governance debates and on-line communities, is that having good, clear, and previously-agreed process is exactly what creates the space for people to be gracious and collaborative even when they strongly disagree with the opinions of others.

Additionally, he said, it is easier to accept a decision that one doesn't agree with if one doesn't feel outmaneuvered during the process.

An earlier version of these changes generated a fair amount of discussion but little in the way of opposition or substantive changes. Perhaps the biggest point of discussion was a suggestion that a tie vote in the Technical Committee should automatically trigger a general resolution to make the decision rather than relying on the chair's casting vote. In the end, though, the consensus seems to be that such a provision would add more complexity for a small benefit, so it seems unlikely to happen.

In response to the second posting, Timo Röhling suggested fixing the length of the discussion period with almost no provision for changes; that, Röhling said, would minimize attempts to game the rules and would make things more predictable for developers. Allbery expressed some sympathy for that point of view, but also said a bit of flexibility could help the project deal with urgent issues in a timely manner. Unless others express views on the length of the discussion period, the proposal seems unlikely to change.

There seems to be a fair amount of support for Allbery's proposal but, in this case, "a fair amount" may not be enough. This is a constitutional change, meaning that a general resolution vote (under the old rules) will be required, and the resolution must pass with a 3:1 supermajority. Allbery does not want to actually propose a general resolution until he feels that it has a good chance of attaining that level of support, so he has asked for anybody who would not support it to explain why. There has been little response to the second posting, which is perhaps a sign that the project is, indeed, ready to make these changes.

---

to post comments