General Resolution: Voting secrecy

Time Line

Discussion Period: 2022-02-23 2022-03-11
Voting period: Sunday 2022-03-13 00:00:00 UTC Saturday 2022-03-26 23:59:59 UTC

Proposal A Proposer

Sam Hartman [[email protected]] [text of proposal] [amendment]

Proposal A Seconds

  1. Russ Allbery [[email protected]] [mail]
  2. Steve McIntyre [[email protected]] [mail]
  3. Bill Blough [[email protected]] [mail]
  4. Filippo Rusconi [[email protected]] [mail]
  5. Sean Whitton [[email protected]] [mail]
  6. Pierre-Elliott Bécue [[email protected]] [mail]

Proposal A

Hide identities of Developers casting a particular vote

Rationale

During the vote for GR_2021_002, several developers said they were uncomfortable voting because under the process at that time, their name and ballot ranking would be public. A number of participants in the discussion believe that we would get election results that more accurately reflect the will of the developers if we do not make the name associated with a particular vote on the tally sheet public. Several people believed that the ranked votes without names attached would still be valuable public information.

This proposal would treat all elections like DPL elections. At the same time it relaxes the requirement that the secretary must conduct a vote via email. If the requirement for email voting is removed, then an experiment is planned at least with the belenios voting system. belenios may provide better voter secrecy and an easier web-based voting system than our current email approach. If this proposal passes, adopting such an alternative would require sufficient support in the project but would not require another constitutional amendment.

This proposal increases our reliance on the secretary's existing power to decide how votes are conducted. The lack of an override mechanism for secretary decisions about how we conduct votes has not been a problem so far. However, if we are going to rely on this power to consider questions like whether the project has sufficient consensus to adopt an alternate voting mechanism, we need an override mechanism. So, this proposal introduces such a mechanism.

Summary of Changes

1) Do not make the identity of a voter casting a particular vote public.

2) Do not require that votes be conducted by email.

3) Clarify that the developers can replace the secretary at any time.

4) Provide a procedure for overriding the decision of the project secretary or their delegate. Overriding the decision of what super majority is required or overriding the determination of election outcome requires a 3:1 majority. The chair of the technical committee decides who conducts such votes.

6) Codify that our election system must permit independent verification of the outcome given the votes cast and must permit developers to confirm their vote is included in the votes cast.

General Resolution

The developers resolve to make the changes to the Debian Constitution embodied in git commit ed88a1e3c1fc367ee89620a73047d84a797c9a1d. As of February 23, 2022, this commit can be found at [https://salsa.debian.org/hartmans/webwml/-/commit/ed88a1e3c1fc367ee89620a73047d84a797c9a1d

For convenience a word-diff of the changes is included below. In case the diff differs from the commit, the commit governs.

@@ -179,9 +179,27 @@ earlier can overrule everyone listed later.</cite></p>
  </li>

  <li>
    [-<p>In case of-]{+<p>Appoint+} a [-disagreement between-]{+new secretary.
In the normal case ( §7.2) where+} the project
    leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary,
[-appoint a new secretary.</p>-]{+this power of+}
{+    the developers is not used.</p>+}
  </li>
  {+<li>+}
{+    <p>Override a decision of the project secretary or their+}
{+    delegate.</p>+}

{+    <p>Overriding the determination of what super majority is required+}
{+    for a particular ballot option or overriding the determination of+}
{+    the outcome of an election requires the developers to agree by a+}
{+    3:1 majority.  The determination of the majority required to+}
{+    override a decision of the secretary is not subject to+}
{+    override.</p>+}

{+    <p>The chair of the technical committee decides who acts as+}
{+    secretary for a general resolution to override a decision of the+}
{+    project secretary or their delegate. If the decision was not made+}
{+    by the chair of the technical committee, the committee chair may+}
{+    themselves act as secretary. The decision of who acts as secretary+}
{+    for such a general resolution is not subject to override.</p>+}
</ol>

<h3>4.2. Procedure</h3>
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p>
    <p>
       Votes are taken by the Project Secretary. Votes, tallies, and
       results are not revealed during the voting period; after the
       vote the Project Secretary lists all the votes {+cast in sufficient
detail that anyone may verify the outcome of the election from the votes cast.
The+}
{+       identity of a developer casting a particular vote is not made+}
{+       public, but developers will be given an option to confirm their vote
is included in the votes+} cast. The voting period is 2 weeks, but may be
varied by up
       to 1 week by the Project Leader.
    </p>
  </li>

@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p>
  </li>

  <li>
    <p>Votes are cast[-by email-] in a manner suitable to the Secretary.
    The Secretary determines for each poll whether voters can change
    their votes.</p>
  </li>
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p>
  necessary.</li>

  <li>The next two weeks are the polling period during which
  Developers may cast their votes. [-Votes in leadership elections are-]
[-  kept secret, even after the election is finished.</li>-]{+</li>+}

  <li>The options on the ballot will be those candidates who have
  nominated themselves and have not yet withdrawn, plus None Of The

Proposal B Proposer

Judit Foglszinger [[email protected]] [text of proposal] [update]

Proposal B Seconds

  1. Scott Kitterman [[email protected]] [mail]
  2. Felix Lechner [[email protected]] [mail]
  3. Louis-Philippe Véronneau [[email protected]] [mail]
  4. Mathias Behrle [[email protected]] [mail]
  5. Tiago Bortoletto Vaz [[email protected]] [mail]

Proposal B

Hide identities of Developers casting a particular vote and allow verification

Rationale

Give the opportunity to vote for secret voting without needing to additionally vote for unrelated/only slightly related constitution changes; for example for the change of mode of voting from email to something not defined.

As it was mentioned in the discussion, there might be no consensus on which options are direcly related - This option regards the need to allow verification (6)) as directly related to secret votes, because otherwise they would become completely unverifiable.

Summary of Changes

1) Do not make the identity of a voter casting a particular vote public.

6) Codify that our election system must permit independent verification of the outcome given the votes cast and must permit developers to confirm their vote is included in the votes cast.

<h3>4.2. Procedure</h3>
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p>
    <p>
       Votes are taken by the Project Secretary. Votes, tallies, and
       results are not revealed during the voting period; after the
       vote the Project Secretary lists all the votes {+cast in sufficient detail that anyone may verify the outcome of the election from the votes cast. The+}
{+       identity of a developer casting a particular vote is not made+}
{+       public, but developers will be given an option to confirm that their vote is included in the votes+} cast.

@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p>
  necessary.</li>

  <li>The next two weeks are the polling period during which
  Developers may cast their votes. [-Votes in leadership elections are-]
[-  kept secret, even after the election is finished.</li>-]{+</li>+}

Proposal C Proposer

Holger Levsen [[email protected]] [text of proposal]

Proposal C Seconds

  1. Mattia Rizzolo [[email protected]] [mail]
  2. Philip Hands [[email protected]] [mail]
  3. Mathias Behrle [[email protected]] [mail]
  4. Santiago Ruano Rincón [[email protected]] [mail]
  5. Gunnar Wolf [[email protected]] [mail]
  6. Sven Bartscher [[email protected]] [mail]

Proposal C

Reaffirm public voting

Since we can either have secret and intransparent voting, or we can have open and transparent voting, the project resolves to leave our voting system as it is.

Rationale

The GR proposal for secret voting is silent on implenentation details, probably because secret and transparent voting is, well, impossible to achieve fully, so this GR is bound to a similar fate as the 'publish debian-private' vote, which was voted for and then was never implemented.

A voting system which is transparent only to some, is undemocratic and will lead to few people in the know, which is diagonal to Debians goals of openness and transparency.

And then, early 2022 is not the time for rushed changes like this, which is also why I explicitly want to see "keep the status quo" on the ballot, and not only as "NOTA", but as a real option.

Quorum

With the current list of voting developers, we have: 

 Current Developer Count = 1023
 Q ( sqrt(#devel) / 2 ) = 15.9921855917195
 K min(5, Q )           = 5
 Quorum  (3 x Q )       = 47.9765567751584

Quorum

Data and Statistics

For this GR, like always, statistics will be gathered about ballots received and acknowledgements sent periodically during the voting period. Additionally, the list of voters will be recorded. Also, the tally sheet will also be made available to be viewed.

Majority Requirement

Proposal 1 and 2 need a 3:1 super majority

Majority

Outcome

Graphical rendering of the results

In the graph above, any pink colored nodes imply that the option did not pass majority, the Blue is the winner. The Octagon is used for the options that did not beat the default.

In the following table, tally[row x][col y] represents the votes that option x received over option y. A more detailed explanation of the beat matrix may help in understanding the table. For understanding the Condorcet method, the Wikipedia entry is fairly informative.

The Beat Matrix
 Option
  1 2 3 4
Option 1   72 114 149
Option 2 144   142 185
Option 3 137 107   163
Option 4 94 61 68  

Looking at row 2, column 1, Hide identities of Developers casting a particular vote and allow verification
received 144 votes over Hide identities of Developers casting a particular vote

Looking at row 1, column 2, Hide identities of Developers casting a particular vote
received 72 votes over Hide identities of Developers casting a particular vote and allow verification.

Pair-wise defeats

The Schwartz Set contains

The winners

Debian uses the Condorcet method for voting. Simplistically, plain Condorcets method can be stated like so :
Consider all possible two-way races between candidates. The Condorcet winner, if there is one, is the one candidate who can beat each other candidate in a two-way race with that candidate. The problem is that in complex elections, there may well be a circular relationship in which A beats B, B beats C, and C beats A. Most of the variations on Condorcet use various means of resolving the tie. See Cloneproof Schwartz Sequential Dropping for details. Debian's variation is spelled out in the constitution, specifically, A.6.

Debian Project Secretary