On Sun, 13 Mar 2022 17:53:12 +0100 Debian Project Secretary - Kurt Roeckx <secret...@debian.org> wrote:
> Hi, > > A part of the ballot option in choice 2 was missing. Here is the > corrected ballot. > > 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 secret...@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_secr...@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_secr...@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 > [4] Choice 1: Hide identities of Developers casting a particular vote > [1] Choice 2: Hide identities of Developers casting a particular vote and > allow verification > [3] Choice 3: Reaffirm public voting > [2] 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/yhotrixtz3aip...@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 ( §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----- > -- Michael Lustfield
pgpw8sQEVDfhC.pgp
Description: OpenPGP digital signature
