Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

General Resolution: Voting secrecy: Second call for votes

0 views
Skip to first unread message

Debian Project Secretary - Kurt Roeckx

unread,
Mar 19, 2022, 7:10:03 AM3/19/22
to
Hi,

This is the second call for votes for the General Resolution about
voting secrecy.

Voting period starts 2022-03-13 00:00:00 UTC
Votes must be received by 2022-03-26 23:59:59 UTC

The following ballot is for voting on changing the resolution process.

This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secr...@debian.org.

The details of the general resolution can be found at:
https://www.debian.org/vote/2022/vote_001

Also, note that you can get a fresh ballot any time before the end of
the vote by sending a signed mail to
bal...@vote.debian.org
with the subject "gr_vote_secrecy".

To vote you need to be a Debian Developer.

HOW TO VOTE

To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:

gr_vote...@vote.debian.org

The form you need to fill out is contained below in this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.

There are 4 choices in the form, which you may rank with numbers between
1 and 4. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 4.

You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.

To vote "no, no matter what", rank "None of the above" as more desirable
than the unacceptable choices, or you may rank the "None of the above"
choice and leave choices you consider unacceptable blank. (Note: if the
"None of the above" choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
"None of the above" choice by the voting software).

Finally, mail the filled out ballot to: gr_vote...@vote.debian.org.

Don't worry about spacing of the columns or any quote characters (">")
that your reply inserts.

NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring. You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.

The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.


VOTING SECRECY

This is a non-secret vote. After the voting period is over the details on
who voted what will be published. During the vote itself the only
information that will be published is who voted.

You can encrypt your message to the voting system to keep your vote secret
until the end of the voting period. The software will also try to keep
your vote secret and will encrypt the reply it sends to you.

VOTING FORM

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
6acf7f89-3eb2-492c-8715-98ae65b5f9d2
[ ] Choice 1: Hide identities of Developers casting a particular vote
[ ] Choice 2: Hide identities of Developers casting a particular vote and allow verification
[ ] Choice 3: Reaffirm public voting
[ ] Choice 4: None of the above
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

----------------------------------------------------------------------

BALLOT OPTIONS


Choice 1: 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 [1]. 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.

[1]: https://lists.debian.org/YhoTRIxt...@roeckx.be

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 ( &sect;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



Choice 2: 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>+}


Choice 3: 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.

Choice 4: None of the above
===========================

This is the default option. Rank this option higher than the unacceptable
choices.


VOTE RESULTS

The responses to a valid vote shall be signed by the vote key created
for this vote. The public key for the vote, signed by the Project
secretary, is appended below.

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGIs0tMBEACuLjJ6zBlCT9+nvzQdhZuuxg9ECSYZu8z0ZJ3RnqMkpw+45Riv
jmxlOC6bbkFloRdDrhNTIFFgdp92/sFnWwd0rQ6SvZbVGjiaXTggO4gIoXWGCJyd
QGNAeUp7DIoORTok1HanzmSue0xJU+rZRUk3ACbN7hrlw1wC9UcOX2pptVeubcVL
fh/iZL6TJlgcZT5mWTpt1qkNHh/Y2uPIafzGmOWSM7AithGDEtw3MaGdH9hli7qo
zgx+3CcZBIAI+bHb9Xfnx3b1qRmC6kFOpETBbzBDz1g66xlSu8aYM1ldIgiDSyip
2GICxmNzCB5LvdQ6wxCMuzRg/a8hYYwbNpdxpzvMbJkqMqPTpCncmxwZR7w6eo9b
U1Rab6ILyIjrFn7UrkIYSKnPG8muI0OCgMJcecx9s/r2MVphQKnA0/H/+HHJ19KV
aWfnxqVnT/DbeKWMLYyv0A8+anownroHmhUOJUB5vbJV4qEWLnFMQ9lkxra2esZF
voGgk9+hXgPjcNz3D+lK51is0x6MBYqlfa32YrzbP+vrYws1j8+V+d2bbxQ5pNMs
B3IAqCLJxWTMIFAAl4ENu/R+kgdHJYkTAADO+puv/LA5DtvSwnswhPMEsenjROi4
bJMmOfapGPlRBzD038K+d8Dt/wtyf/V1tm+GopUB/YaQ9l8BQZBshOgFgQARAQAB
tDBWb3Rpbmcgc2VjcmVjeSA8Z3Jfdm90ZV9zZWNyZWN5QHZvdGUuZGViaWFuLm9y
Zz6JAj4EEwEIACgFAmIs0tMCGwMFCQAbr4AGCwkIBwMCBhUIAgkKCwQWAgMBAh4B
AheAAAoJEIibeWkr1bTjVqYP/3ra2wGH/L5TWI2ohEkvFmg53/NAE33wmgjtjnbU
tZkEQPWvCbeg6iJKgk7O4AAx9XgUu0HFRY+FQSN4lsC+SyaG53WQ9baDGia6jc4Y
iHMgELdOPNC47yp4qC30AV6nBptjjJv2QyYq8gOej/I2hSf5YtpdnA7Q3lsymA9E
+iPIcV1QO9IX0WU3+6Hu3PP7rKugJTsM1YjlrOzjHB3WAPyngw38drcIxBc/d7Uy
1FRD/l2I5SBvRPOEiZH/2hZXbeT1yQkphwTVpHfsBtkPxnv5ERILBWRVOW5lKcg4
yyXASzkbngaIbfacgC0b17WfEvX+yeKWFAeEn2/A0uRrVkgjY1yT7kfFq8OFNqRc
v9FW3PQDG6pFMKdtvzaI0PMujclXhtp29FzHqBGdLiOuJgn6qJ0IfUoKPtGR7J6o
AiB7ojGH14wiXxWJA8cQpyxz1+6x3bCvxlDU+TW3qn1WNYDON+1USVpwOvUct8ru
jn2a2OoFYxI2gun1ZPuqQdhHyTKuVhNJ5674NlmBVGG1YlQWQVxElEreMkqUdS17
w8CjNEu+yCkl3dsQuZLdOrIcgEqSZt22i6HA5hldWD8JiJ46iMsEZIfYelqHBuDe
J+OmT4PR0Q/klrwA3Jq06xEr/o2RvDzzvT39KW4QBOVZiQPwLV/8BIQ/TDqoIvoI
NjoyiQIzBBABCgAdFiEE5eUlYN2RxVbdvaXQIGTFNkHCXl0FAmIs0yoACgkQIGTF
NkHCXl2QpQ/8CHQeNMwzDqxu6mR9wrOuM37J5QoHX1wUbr5yXVqOXpVjPHLvbRWW
OVf798x+jQ92NFUi1ANYn2nr9Fgtp0YNkpX3w8nd32j3SivtB1+TeoFXJbvtJbT+
F3KI0X63FTFiuNLU3rcupO+b78jRO3awJnxw3eiWM6KGAraE146mqVIk5PBJFF0h
RJkg+GK5SLZ0otRpNAquoN6HcX9ToLGc2HlDL8S4IWVqFKPh8R8Eb6RbKEjM4htj
2azL06CCHZlACrg3I68zO9bhRXdwbyOzbQ6M3jymvSqJl0fB9DTDAFzaG1LhF+00
ghXqqJeAexQzcN5tZ0Xc4ZZfNFjvGBVmBoucHHO11L2CwNZPzH2DrLPuH6KzsmoE
wq/XHiLAonqHIsc/YM32l98v+8Ro1LreyGqc1KYKvKnvlDg1C3KKK6ObcDsL02IL
yw2Ksu4ZJLv73aqOjw/B04Qyf82JKVGkmVe7FwjjsZLDDrH1ZcZ03g2057Du0A/r
2bm6Y6+dmYyrjWfKmAVJRbPHttnt7T2OUJSg8oThBBe3FKTq5O1i5Vba+cjHP/QR
YLZtumRi9JdACs6VI6KcJbf7rvTd6NcOp3NNjog5NgjAhuVjTQAi5364QAlYO2q/
7KA/UlciI2jyYOu5oirFeOGLCo98rqeoIi+tf7whXT6z+cqCvcv0L/+5Ag0EYizS
0wEQAMi+pNlhNpgmUW8NGNKowBbj1HjZnSMNCeuJl4J0pit6WzF6ulLY0uuA9rEu
/EO46tGU2iHu1QzLTmtpj480mm9FPLiJAv8dooKRCyjdkR9hw33iCZSI/u8pKI1i
+EbovJEVVvX2g5ci1cMQ7G8uRhC3GQ/63yBiWQ6OT+retorKFAnQY14S1i8r8eU1
gEuTOJsUU/J8XylrMOSSfkU5NnyE9fZzB07+1e8mrsXlq9qQhntcdCQ46q7f87vw
iG5gzdXhy7tYpNHUd9syZyQMTYxxq4gaU8B9cHX5RUFqvwTR9WqBrv8qMeWNzZbg
IYnVCyS6f44lWtyopSUSw5aAOwYyYyIfIL9iym1rRJqReIUYA5fT5kSchbR9LUAI
Pfo/mZII8uCqirD+l3cDn9syiuATW5ubnVlCGWLFdbtZkrPmwU7n38Q7YrZK59o7
cHR1lQ5qwim5B0fF90Qo/nRgwOk4fWNxhlwMCdUoeHtoAZSmuDPK8oDp6SqVdxaW
Qrsx2hnG6rKoclVMwTyEyNazcDaq9ZzMlIFRArw791J/lK3MtxnsXz3t2vonbEe1
mvblJ8celOd3NwZU1JDtJxSrNXgI1YJxtyu53m3rlWE7G9/s7JrEpS1fbyDux+Uo
dWc8LifnOD/AKKINNM0mJOyfcZa9wg1/rtyKMJ1zgHkZA25RABEBAAGJAiUEGAEI
AA8FAmIs0tMCGwwFCQAbr4AACgkQiJt5aSvVtOONlBAAqbbaZ3+iVNxppqjxB3+Q
/v/olcD2OHBT7qRG5Lflkg/NucjxfF/6OGcRk2dX4kRxefEBG1B2gLsbrUKXnPCP
Z97ElV5OuMXOrWmYa8XYLLK3nee/b5wxAKQp60qhcD7qdmWigAnZXOLhZjeRsRym
QsC2Zqs4vRFKKgZ+SftMRIZ1C9lLXeaWvyZm+szxUz6v82hpwVhHMirJCBa+DM/b
WXwOnlEF7j/8M1noMzUJaYXXOYVHjJSCJkWV4vvlVwKp1MNKdbYwq7jKHZxdxBMB
y9w4TReIlNYLgaGzo94rBA9MVF4OOniLjEHZKx303IOSFqZlnFtEAHZUGON6uVBC
40nISOGgLON2BKej8kRR+5u46m1x7mleeX0cUMLZGTvTNSfgedpCaGGcyWXRTJjh
Nl/tEb6FJ5n2YAmNg7rx6EgGw7KcGzhLwcEIhess4zAjjOMYMXsG+xHe8jLMMA+v
dl/h62M+KKWne7zTraPvruPfSNazi4dZ+OQSGd1IU7THIQeLzPQy3xmaGODCT2Rb
rgG5a3UmG3beq8INyM32dTCPBdaylVEvHCFV7pLJQqV4rbsjI4y1Pj80Q1nKAWd6
KaEdm9RLst8dlGr/yqF2eKW6Anrq0BnIk2P+1WUNT6kYw3uR54zEMJsEyHhGthHv
rBx9Eic2hgSnl4hB+jxtJJ0=
=anKA
-----END PGP PUBLIC KEY BLOCK-----

signature.asc
0 new messages