Language Selection

English French German Italian Portuguese Spanish

Possible changes to Debian's decision-making processes

Filed under
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.

Read more

More in Tux Machines