Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

Debian has been working on some "constitutional maintenance" of late; a general resolution (GR) on tweaks to the project's decision-making processes passed at the end of January. As part of the discussion surrounding those changes, the question of secret voting came up; currently, Debian publicly lists every voter for a GR and their ranking of the options. Another GR has been proposed to change that, but the discussion has shown that the definition of "secret" is not exactly the same for everyone. In addition, secret voting is not the only change being proposed.

A bit of history

The proximate cause for the interest in secret ballots is the controversial GR that was proposed and voted on in the early part of 2021; it proposed that the Debian project make a statement regarding Richard Stallman's return to the FSF board of directors. The voters decided that Debian would make no distribution-wide statement about that event, by a fairly close margin, but some people in the discussion were uncomfortable voting on the GR, given that their choices would be fully visible to the internet at large. The worry was that proponents or opponents of all the myriad "sides" in the debate would harass those who voted in the "wrong" way.

Back in November, Sam Hartman asked if the secret ballot question should be handled as part of the in-progress GR-process tweaking, or if it should be handled as a separate GR after that had run its course. The consensus seemed to agree with Hartman's assessment that it could overcomplicate the ballot, so he decided to defer it. In that message, though, he outlined the changes he would make to the Debian Constitution to change the GR vote to be a secret one. It would, essentially, follow the lead of the elections for the Debian project leader (DPL), which make all of the ballots public, along with the list of voters, but do not provide a mapping from voter to ballot.

The changes he proposed also sparked some discussion around the role of the project secretary. Hartman's changes said: "Votes are cast in a manner suitable to the Secretary." That removed the "by email" phrase because there might be systems for anonymous voting that do not use email. But, as Carsten Leonhardt pointed out, the manner of voting "needs to also be suitable to the voters".

Secretarial overrides

So, when Hartman returned to the subject after the vote on the earlier GR, in late January, he started with the question of how to handle disagreements between Debian developers (DDs) and the secretary. The constitution currently does not have a mechanism for the developers to override a decision of the secretary. Leonhardt noted one possible area for disagreement, voting systems, but Hartman wanted to solve the more general problem, so he proposed a change that would allow developers to override the secretary with a simple majority vote.

There are, however, two situations where a simple majority does not make sense, he said. The secretary decides which votes require a 3:1 supermajority, so overriding that kind of decision should also require a 3:1 vote. In addition, the secretary determines the outcome of all elections (including GRs) in Debian, some of which might require a supermajority, so it makes sense to require a 3:1 vote to override a vote outcome, as well, he said.

Don Armstrong pointed to clause 4.1.7 (in the section on the powers of developers) as a way to override the secretary: "In case of a disagreement between the project leader and the incumbent secretary, appoint a new secretary." But Hartman was concerned that 4.1.7 was somewhat ambiguous because of the "disagreement" language, so he said that he planned to address that as well in his secret-voting proposal.

Secret?

Jean-Phillipe Mengual said that votes in Debian should be secret by default, unless a majority of developers voted to change that for a particular GR. But Holger Levsen wondered what "secret" meant in this context. Hartman started a new thread with a lengthy reply: "TL;DR: I'm proposing that the way we handle DPL elections today is a good start for what secret means."

He outlined the mechanism for project leader elections: in addition to the public ballots (with no mapping to the actual voter), voters get a cryptographic hash that they can use to show that their vote was included in the totals. He listed two possible attacks against that system, both of which could be detected if voters (and those who can vote but did not) verify the election results. If the actual ballots are not retained, and the secretary, who oversees the process, is trustworthy: "I think those attacks are acceptable residual risk from a security standpoint".

Russ Allbery said that he was not quite as sure that voluntary verification was sufficient, however:

I'm a bit concerned that any scheme that doesn't build the cryptographic verification into the process and instead relies on people going out of their way to do verification is not going to be widely verified, and therefore it does create new risk if some future iteration of Debian has a less trustworthy secretary than we do today. To be clear, this is not a new risk; we're already living with this risk for DPL elections and maybe this should be within my risk tolerance. But it's not as clearly within my risk tolerance as it is within Sam's.

There are other risks that come with the current DPL voting process, Bill Allombert said. A developer could be forced to reveal the secret code returned by the devotee vote system, which would expose their vote. In addition, a group of voters on one side of an issue could work together to show that everyone else voted a particular way. Either of those would break the anonymity of the voting.

Hartman acknowledged those weaknesses, but noted that the problems already exist for DPL elections; he wondered if GR votes were categorically different. Allombert replied that the DPL votes are secret "as a courtesy to the candidates". He is not in favor of secret GR ballots, though he does recognize the problem that arose from the Stallman GR. He feels that GRs of that nature should be avoided:

[...] the Debian project is not the collection of opinions of its members since the members only agreed to fulfill the social contract when acting on behalf of Debian and not in general, and that their opinions outside of this is a private matter that must not be [probed], and that even the [aggregate] result of the vote is already leaking information that Debian project has no purpose to gather and publish.

As he refined his proposal, Hartman posted two more versions of the wording for discussion purposes, one on February 13 and another on February 20. As might be guessed, since this is Debian, discussion ensued. Armstrong asked about "specific examples of where someone wasn't able to vote their true preference because the vote was public". He noted that he perhaps sees his role differently with regard to voting than some do:

My personal reasoning is that I see my role as a voting project member as more of a stewardship role where I'm trying to decide what is best for the project, rather than what is best for me personally, and I want to be seen as being a good steward for the project. I also think the large number of voters masks the impact of a single individual vote. [But maybe this is a personal safety issue? Perhaps people should be able to optionally mask their identity when voting? Not sure.]

Hartman said that his country has secret ballots to elect its representatives, but that those representatives are expected to vote publicly in order to be held accountable by those who will possibly re-elect them. But Debian developers are not elected representatives; will they make better choices for the project, he asked, if they have to worry about how their vote will be perceived by others, possibly years down the road?

He also said that he and others were subjected to harassment because they sponsored or supported certain ballot options on the Stallman GR; he pointed to several possible scenarios where developers might not vote their conscience (or at all) because of concern about the reactions from others (e.g. employers or projects). He has not really looked at the individual votes in the past and was uncomfortable doing so, but he did note a response from Philip Hands that contained a valid use for the list of votes made. Hands said:

I have used the results of votes in the past to start conversations with people that I disagree with in some issue in order to better understand how they came to the other view. One can generally find someone on the other side of the argument who you already know and respect, which makes it much harder to dismiss them as an idiot. I'd miss that in a properly secret ballot.

But Hartman said that sponsors and public supporters of various ballot options should "be sufficient that it will not be difficult to find someone who can explain an alternate position even if we hide who voted for what". Karsten Merker replied that he was in favor of secret ballots, in part because the topics of GRs has shifted over time from "either technical or purely Debian-internal organizational issues" to questions like Stallman's return to the FSF board, which are "about a highly explosive public political debate completely external to Debian where there was IMHO absolutely no reason for Debian as a project to become involved at all". Public voting leaves developers without good choices:

Forcing this GR on the developers left all developers with only two choices: either to not vote at all and as a result have a highly explosive political statement that they potentially don't agree with (or even actively disagree with) published in their name, or take part in the vote and be forced to have their political views on the matter made public, political views which they otherwise wouldn't have made public and whose publication could easily have negative effects for them given the political climate around the whole matter - a climate where people in both "camps" had been sharpening their pitchforks and where having one's personal views on the matter published (regardless of which "side" one voted for) might well have negative consequences for one's further professional career.

Making the vote secret does not solve the problem of potentially having project statements made that a developer does not agree with, but it would allow developers to vote against them without subjecting themselves to various repercussions. In the threads, there were others who reported discomfort with voting publicly on GRs in the past, and reported that they had heard privately from developers who did not vote because of that.

Given that it is GRs on political positions that seem to be the most fraught, Hands suggested that perhaps the project could come to a "consensus not to even attempt these sorts of position statements in future, since all they do is highlight divisions". It is not surprising that those kinds of GRs are divisive:

Given that we generally want DDs to be drawn from as diverse a population as possible, we should expect our views on pretty-much any subject other than Free Software to represent the full spectrum of opinion, so drawing an arbitrary line somewhere and then getting the project to divide on which side we should stand as a group is not likely to give a useful result, but will give people reasons to be upset with one another.

While Allbery generally agreed with the sentiment, he did not really think the project could avoid divisive GRs in the future; he is concerned about moving forward without a way to mitigate the effects of those kinds of votes. Meanwhile, he gave some examples of where the problem might occur again:

I find it hard to escape the conclusion that we're going to have some vote in the future that will pose similar risks. Examples of lines of discussion that I think the project cannot (and should not) entirely avoid but that could lead to such a problem include Debconf venue selection, anything related to the project code of conduct including whether we should have one, and membership actions and their potential overrides under 4.1.3. I'll also point out that even technical issues have become heavily polarized and have led to at least borderline [harassment] based on publicly stated positions (see systemd).

General resolution

Though Hartman had earlier expressed some pessimism about his changes gaining enough support to consider moving forward with a GR, that changed over the course of the discussion. On February 23, he proposed the GR, which would make five specific changes to the constitution: switch to secret ballots, not require elections to be conducted by email, clarify that developers can replace the secretary, provide a way for developers to override the secretary, and codify that elections need to provide a means for voters to verify their votes were included and permit independent verification of the outcome. The proposal immediately attracted a half-dozen "seconds", which is sufficient for it to make its way to voters.

Before that, though, amendments and other ballot options can be proposed. Armstrong wanted to ensure that email was still an option: "e-mail should continue to be an option for casting votes even while alternative methods of casting ballots might also be allowed". Hartman was not opposed to the overall idea, but did not want to require a 3:1 supermajority to change the constitution in order to switch away from email to some other system. Armstrong agreed with part of that, but did not want to completely eliminate the email option without a 3:1 vote:

I don't want it to take a 3:1 majority to add additional methods (web based, I'm presuming), but I think not allowing a signed (and/or encrypted) emailed ballot to count should require a 3:1 majority. [The former potentially allows more valid voters to vote, the latter potentially reduces who can vote.]

Hartman recommended a ballot option for email in that case. Bundling all five of the changes that Hartman proposed was seen as a possible problem by Judit Foglszinger and others. Foglszinger proposed a ballot option that just encompassed two of the changes: secret ballots and the codification of voter and outcome verification. The email change, secretary removal provision, and secretarial override change would be dropped: "So it's the proposed GR minus the changes not directly related to introducing secret votes."

Once again, Hartman expressed concern about needing to change the constitution in order to adopt a new voting system, but Scott Kitterman did not see that as a real problem: "So far the rate of change in voting systems leads me to believe this is a quite manageable burden." Beyond that, Bdale Garbee worried that changing the system without a GR could lead to a less well-understood voting system:

Requiring a GR to change the mechanism seems like a completely reasonable way to both vet the proposed change, and ensure a maximum number of potential voters understand what's changing.

Martin Michlmayr said that the two changes on replacing or overriding the secretary seem unrelated to hiding voter's identities, but make up most of the changes in the text. If those two are directly important to secret voting, that should be made clearer, he said; otherwise, they should not all be bundled together. Hartman replied that the constitution already gives the secretary broad powers over elections, but there is currently no clear recourse if developers disagree with the secretary's decision. So he would like to see all of the changes adopted, but he is not comfortable adding secret voting without putting in some kind of recourse for an unpopular decision by the secretary.

That raises the specter of a combinatorial explosion of options, though it is perhaps not as bad as all possible combinations of the five options. The two secretary curbs seem to go together, as do the two vote changes, which, when coupled with the email change, might reduce it to only all possible combinations of the three options—along with "further discussion", or "none of the above" as it is now known, of course.

That's where things stand at the moment, though the conversation is ongoing. The full ballot will shake out relatively soon, as there will be two or three weeks of discussion and ballot additions, starting February 23. One of the tweaks made in the recent decision-process GR has firmed up the timing of the discussion period, so it will be three weeks long unless the DPL reduces it by a week, which seems relatively unlikely. After that, a two-week voting period will follow. All of that should play out over the next month or so. It will be interesting to see where it leads.

---

(Log in to post comments)