[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: General Resolution: Voting secrecy: First call for votes: corrected ballot



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


> 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/YhoTRIxtz3AIpO+g@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-----
> 
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEBs1j101ZjEpH5CyWA6iJGnZa0IUFAmIwlJgACgkQA6iJGnZa
0IXinBAAm9dXMdxxmGJFV2AhNIYFxoxkl8RMkWRatRXNFKOZjSuWXF96i5ct0keV
VYmhiR3waSz5SEDER171PHFthuYU5jZu1k6eXgy3AvkTVNYdGFG9OKxk1joT68GR
t8x3m2S8Je0E4slbAJPbLNltdLT/y/p6KbNB32chaoJYdydNfrq/gkkI1hl1wK0y
8wh31NHFj5OgZaiwVfTOZ/02mqaLSbiRPA0/tgrNl77/l9LhuoKkgMQscEii/Sav
ijrBMTHSloTFx7+ZwmYNl90j+L5Gpe7O6tkt5j2J3ZDuHS2PNyHK1grlv/g7LGNN
Frh1W1Hg59rEZDCObxb05/QWh2XkQFO8CdIBLcvJjhq8VNtpa127NcdWZjaR8T/d
PhlYCMRa6PO/ZIYQ4eVhwUiBhMJIT7S+pzbcXReK+m3XQ2CK03RGpcTSvVXuyVbf
G8dx2Rf72J+3wCp32jUQyyt42sT0WO4Km3DqQkdLnUC9xn7WTd5jBCv2SDqR9whG
+u7mXQ72RgsXept3NO8rgEf9p2SQ+isloDzQ8LAT2XpQe+zjTyQKeTOs8SWdqI2C
nDtbh3lQtISI8r7rb0I/LFMK2FXCnOT3l7evpNzqVLCRq9qZFYnkTD1Em8qUFsug
sq+rae+r7ZIXsfKjyV5Wf+evE4DV2bCbKiZreTKHZ3LzRPrlUnM=
=osfA
-----END PGP SIGNATURE-----

Reply to: