⁣Obtener BlueMail para Android ​

En 13 mar. 2022 0:44, en 0:44, Debian Project Secretary - Kurt Roeckx 
<secret...@debian.org> escribió:
>Hi,
>
>This is the first call for votes on 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 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
>[ ] 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/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
>
><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: Amend resolution process, allow extension of discussion
>period
>========================================================================
>
>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-----

Reply via email to