Obtener BlueMail para Android
En 13 mar. 2022 0:44, en 0:44, Debian Project Secretary - Kurt Roeckx <
secretary@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 secretary@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
ballot@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_secrecy@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_secrecy@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/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
<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>
<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-----
<html><head></head><body style="zoom: 0%;"><div dir="auto"><br><br></div>
<div dir="auto"><!-- tmjah_g_1299s -->Obtener <!-- tmjah_g_1299e --><a href="
https://bluemail.me"><!-- tmjah_g_1299s -->BlueMail para Android<!-- tmjah_g_1299e --></a><!-- tmjah_g_1299s --> <!-- tmjah_g_1299e --></div>
<div class="gmail_quote" >En 13 mar. 2022, en 0:44, Debian Project Secretary - Kurt Roeckx <<a href="mailto:
secretary@debian.org" target="_blank">
secretary@debian.org</a>> escribió:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="blue">Hi,<br><br>This is the first call for votes on the General Resolution about voting<br>secrecy.<br><br> Voting period starts 2022-03-13 00:00:00 UTC<br> Votes must be received by 2022-03-26 23:59:59 UTC<br><br>The following
ballot is for voting on changing the resolution process.<br><br>This vote is being conducted as required by the Debian Constitution.<br>You may see the constitution at <a href="
https://www.debian.org/devel/constitution">https://www.debian.org/devel/
constitution</a>.<br>For voting questions or problems contact
secretary@debian.org.<br><br>The details of the general resolution can be found at:<br><a href="
https://www.debian.org/vote/2022/vote_001">https://www.debian.org/vote/2022/vote_001</a><br><br>
Also, note that you can get a fresh ballot any time before the end of<br>the vote by sending a signed mail to<br>
ballot@vote.debian.org<br>with the subject "gr_vote_secrecy".<br><br>To vote you need to be a Debian Developer.<br><br>HOW TO VOTE<br><br>
To cast a vote, it is necessary to send this ballot filled out to a<br>dedicated e-mail address, in a signed message, as described below.<br>The dedicated email address this ballot should be sent to is:<br><br>
gr_vote_secrecy@vote.debian.org<br><br>The
form you need to fill out is contained below in this<br>message, marked with two lines containing the characters<br>'-=-=-=-=-=-'. Do not erase anything between those lines, and do not<br>change the choice names.<br><br>There are 4 choices in the form,
which you may rank with numbers between<br>1 and 4. In the brackets next to your preferred choice, place a 1.<br>Place a 2 in the brackets next to your next choice. Continue until you<br>reach your last choice. Do not enter a number smaller than 1 or
larger<br>than 4.<br><br>You may skip numbers, leave some choices unranked, and rank options<br>equally. Unranked choices are considered equally the least desired<br>choices, and ranked below all ranked choices.<br><br>To vote "no, no matter what", rank "
None of the above" as more desirable<br>than the unacceptable choices, or you may rank the "None of the above"<br>choice and leave choices you consider unacceptable blank. (Note: if the<br>"None of the above" choice is unranked, then it is equal to all
other<br>unranked choices, if any -- no special consideration is given to the<br>"None of the above" choice by the voting software).<br><br>Finally, mail the filled out ballot to:
gr_vote_secrecy@vote.debian.org.<br><br>Don't worry about spacing of the
columns or any quote characters (">")<br>that your reply inserts.<br><br>NOTE: The vote must be GPG signed (or PGP signed) with your key that is<br>in the Debian keyring. You may, if you wish, choose to send a signed,<br>encrypted ballot: use the vote
key appended below for encryption.<br><br>The voting software (Devotee) accepts mail that either contains only an<br>unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail<br>(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.<
<br><br>VOTING SECRECY<br><br>This is a non-secret vote. After the voting period is over the details on<br>who voted what will be published. During the vote itself the only<br>information that will be published is who voted.<br><br>You can encrypt
your message to the voting system to keep your vote secret<br>until the end of the voting period. The software will also try to keep<br>your vote secret and will encrypt the reply it sends to you.<br><br>VOTING FORM<br><br>- - -=-=-=-=-=- Don't Delete
Anything Between These Lines =-=-=-=-=-=-=-=-<br>6acf7f89-3eb2-492c-8715-98ae65b5f9d2<br>[ ] Choice 1: Hide identities of Developers casting a particular vote<br>[ ] Choice 2: Hide identities of Developers casting a particular vote and allow verification<
[ ] Choice 3: Reaffirm public voting<br>[ ] Choice 4: None of the above<br>- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-<br><br><hr><br><br>BALLOT OPTIONS<br><br><br>Choice 1: Hide identities of Developers casting a
particular vote<br><hr><br><br>Rationale<br>=========<br><br>During the vote for GR_2021_002, several developers said they were<br>uncomfortable voting because under the process at that time, their name<br>and ballot ranking would be public.<br>A number
of participants in the discussion believe that we would get<br>election results that more accurately reflect the will of the developers<br>if we do not make the name associated with a particular vote on the<br>tally sheet public.<br>Several people
believed that the ranked votes without names attached<br>would still be valuable public information.<br><br>This proposal would treat all elections like DPL elections.<br>At the same time it relaxes the requirement that the secretary must<br>conduct a
vote via email. If the requirement for email voting is<br>removed, then an experiment is planned at least with the belenios voting<br>system [1]. belenios may provide better voter secrecy and an easier<br>web-based voting system than our current email
approach.<br>If this proposal passes, adopting such an alternative<br>would require sufficient support in the project but would not require<br>another constitutional amendment.<br><br> [1]: <a href="
https://lists.debian.org/YhoTRIxtz3AIpO+g@roeckx.be">
https://lists.debian.org/YhoTRIxtz3AIpO+g@roeckx.be</a><br><br>This proposal increases our reliance on the secretary's existing power<br>to decide how votes are conducted. The lack of an override mechanism<br>for secretary decisions about how we conduct
votes has not been a<br>problem so far. However, if we are going to rely on this power to<br>consider questions like whether the project has sufficient consensus to<br>adopt an alternate voting mechanism, we need an override mechanism.<br>So, this
proposal introduces such a mechanism.<br><br>Summary of Changes<br>==================<br><br> 1) Do not make the identity of a voter casting a particular vote<br> public.<br><br> 2) Do not require that votes be conducted by email.<br><br> 3)
Clarify that the developers can replace the secretary at any time.<br><br> 4) Provide a procedure for overriding the decision of the project<br> secretary or their delegate. Overriding the decision of what super<br> majority is required or
overriding the determination of election<br> outcome requires a 3:1 majority. The chair of the technical committee<br><br><h3>4.2. Procedure</h3><br>@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p><
<p><br> Votes are taken by the Project Secretary. Votes, tallies, and<br> results are not revealed during the voting period; after the<br> vote the Project Secretary lists all the votes {+cast in sufficient<br>detail that
anyone may verify the outcome of the election from the votes cast.<br>The+}<br>{+ identity of a developer casting a particular vote is not made+}<br>{+ public, but developers will be given an option to confirm their vote<br>is included in the
votes+} cast. The voting period is 2 weeks, but may be<br>varied by up<br> to 1 week by the Project Leader.<br> </p><br> </li><br><br>@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p><br> </
li><br><br> <li><br> <p>Votes are cast[-by email-] in a manner suitable to the Secretary.<br> The Secretary determines for each poll whether voters can change<br> their votes.</p><br> </li><br>@@ -371,8 +390,7 @@
earlier can overrule everyone listed later.</cite></p><br> necessary.</li><br><br> <li>The next two weeks are the polling period during which<br> Developers may cast their votes. [-Votes in leadership elections are-]<br>[-
kept secret, even after the election is finished.</li>-]{+</li>+}<br><br> <li>The options on the ballot will be those candidates who have<br> nominated themselves and have not yet withdrawn, plus None Of The<br><br><br><br>Choice 2:
Amend resolution process, allow extension of discussion period<br><hr><br><br>Rationale<br>=========<br><br>Give the opportunity to vote for secret voting without needing to<br>additionally vote for unrelated/only slightly related<br>constitution changes;
<br>for example for the change of mode of voting<br>from email to something not defined.<br><br>As it was mentioned in the discussion,<br>there might be no consensus on which options are direcly related -<br>This option regards the need to allow
verification (6))<br>as directly related to secret votes, because otherwise<br>they would become completely unverifiable.<br><br>Summary of Changes<br>==================<br><br>1) Do not make the identity of a voter casting a particular vote<br> public.
<br><br>6) Codify that our election system must permit independent verification<br> of the outcome given the votes cast and must permit developers to<br> confirm their vote is included in the votes cast.<br><br><br><h3>4.2. Procedure</h3><
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p><br> <p><br> Votes are taken by the Project Secretary. Votes, tallies, and<br> results are not revealed during the voting period; after the<br>
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+}<br>{+ identity of a developer casting a particular vote is not made+}<br>{+ public,
but developers will be given an option to confirm that their vote is included in the votes+} cast.<br><br>@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p><br> necessary.</li><br><br> <li>The next two
weeks are the polling period during which<br> Developers may cast their votes. [-Votes in leadership elections are-]<br>[- kept secret, even after the election is finished.</li>-]{+</li>+}<br><br><br>Choice 3: Reaffirm public voting<br><hr><
<br>Since we can either have secret and intransparent voting, or we can have<br>open and transparent voting, the project resolves to leave our voting<br>system as it is.<br><br>Rationale:<br><br>The GR proposal for secret voting is silent on
implenentation details,<br>probably because secret and transparent voting is, well, impossible to<br>achieve fully, so this GR is bound to a similar fate as the 'publish<br>debian-private' vote, which was voted for and then was never implemented.<br><br>
A voting system which is transparent only to some, is undemocratic and<br>will lead to few people in the know, which is diagonal to Debians goals<br>of openness and transparency.<br><br>And then, early 2022 is not the time for rushed changes like this,
which<br>is also why I explicitly want to see "keep the status quo" on the ballot,<br>and not only as "NOTA", but as a real option.<br><br>Choice 4: None of the above<br>===========================<br><br>This is the default option. Rank this option
higher than the unacceptable<br>choices.<br><br><br>VOTE RESULTS<br><br>The responses to a valid vote shall be signed by the vote key created<br>for this vote. The public key for the vote, signed by the Project<br>secretary, is appended below.<br><br>----
-BEGIN PGP PUBLIC KEY BLOCK-----<br><br>mQINBGIs0tMBEACuLjJ6zBlCT9+nvzQdhZuuxg9ECSYZu8z0ZJ3RnqMkpw+45Riv<br>jmxlOC6bbkFloRdDrhNTIFFgdp92/sFnWwd0rQ6SvZbVGjiaXTggO4gIoXWGCJyd<br>QGNAeUp7DIoORTok1HanzmSue0xJU+rZRUk3ACbN7hrlw1wC9UcOX2pptVeubcVL<br>fh/
iZL6TJlgcZT5mWTpt1qkNHh/Y2uPIafzGmOWSM7AithGDEtw3MaGdH9hli7qo<br>zgx+3CcZBIAI+bHb9Xfnx3b1qRmC6kFOpETBbzBDz1g66xlSu8aYM1ldIgiDSyip<br>2GICxmNzCB5LvdQ6wxCMuzRg/a8hYYwbNpdxpzvMbJkqMqPTpCncmxwZR7w6eo9b<br>U1Rab6ILyIjrFn7UrkIYSKnPG8muI0OCgMJcecx9s/r2MVphQKnA0/
H/+HHJ19KV<br>aWfnxqVnT/DbeKWMLYyv0A8+anownroHmhUOJUB5vbJV4qEWLnFMQ9lkxra2esZF<br>voGgk9+hXgPjcNz3D+lK51is0x6MBYqlfa32YrzbP+vrYws1j8+V+d2bbxQ5pNMs<br>B3IAqCLJxWTMIFAAl4ENu/R+kgdHJYkTAADO+puv/LA5DtvSwnswhPMEsenjROi4<br>bJMmOfapGPlRBzD038K+d8Dt/wtyf/V1tm+
GopUB/YaQ9l8BQZBshOgFgQARAQAB<br>tDBWb3Rpbmcgc2VjcmVjeSA8Z3Jfdm90ZV9zZWNyZWN5QHZvdGUuZGViaWFuLm9y<br>Zz6JAj4EEwEIACgFAmIs0tMCGwMFCQAbr4AGCwkIBwMCBhUIAgkKCwQWAgMBAh4B<br>AheAAAoJEIibeWkr1bTjVqYP/3ra2wGH/L5TWI2ohEkvFmg53/NAE33wmgjtjnbU<br>
tZkEQPWvCbeg6iJKgk7O4AAx9XgUu0HFRY+FQSN4lsC+SyaG53WQ9baDGia6jc4Y<br>iHMgELdOPNC47yp4qC30AV6nBptjjJv2QyYq8gOej/I2hSf5YtpdnA7Q3lsymA9E<br>+iPIcV1QO9IX0WU3+6Hu3PP7rKugJTsM1YjlrOzjHB3WAPyngw38drcIxBc/d7Uy<br>1FRD/l2I5SBvRPOEiZH/
2hZXbeT1yQkphwTVpHfsBtkPxnv5ERILBWRVOW5lKcg4<br>yyXASzkbngaIbfacgC0b17WfEvX+yeKWFAeEn2/A0uRrVkgjY1yT7kfFq8OFNqRc<br>v9FW3PQDG6pFMKdtvzaI0PMujclXhtp29FzHqBGdLiOuJgn6qJ0IfUoKPtGR7J6o<br>AiB7ojGH14wiXxWJA8cQpyxz1+6x3bCvxlDU+TW3qn1WNYDON+1USVpwOvUct8ru<br>
jn2a2OoFYxI2gun1ZPuqQdhHyTKuVhNJ5674NlmBVGG1YlQWQVxElEreMkqUdS17<br>w8CjNEu+yCkl3dsQuZLdOrIcgEqSZt22i6HA5hldWD8JiJ46iMsEZIfYelqHBuDe<br>J+OmT4PR0Q/klrwA3Jq06xEr/o2RvDzzvT39KW4QBOVZiQPwLV/8BIQ/TDqoIvoI<br>
NjoyiQIzBBABCgAdFiEE5eUlYN2RxVbdvaXQIGTFNkHCXl0FAmIs0yoACgkQIGTF<br>NkHCXl2QpQ/8CHQeNMwzDqxu6mR9wrOuM37J5QoHX1wUbr5yXVqOXpVjPHLvbRWW<br>OVf798x+jQ92NFUi1ANYn2nr9Fgtp0YNkpX3w8nd32j3SivtB1+TeoFXJbvtJbT+<br>F3KI0X63FTFiuNLU3rcupO+
b78jRO3awJnxw3eiWM6KGAraE146mqVIk5PBJFF0h<br>RJkg+GK5SLZ0otRpNAquoN6HcX9ToLGc2HlDL8S4IWVqFKPh8R8Eb6RbKEjM4htj<br>2azL06CCHZlACrg3I68zO9bhRXdwbyOzbQ6M3jymvSqJl0fB9DTDAFzaG1LhF+00<br>ghXqqJeAexQzcN5tZ0Xc4ZZfNFjvGBVmBoucHHO11L2CwNZPzH2DrLPuH6KzsmoE<br>wq/
XHiLAonqHIsc/YM32l98v+8Ro1LreyGqc1KYKvKnvlDg1C3KKK6ObcDsL02IL<br>yw2Ksu4ZJLv73aqOjw/B04Qyf82JKVGkmVe7FwjjsZLDDrH1ZcZ03g2057Du0A/r<br>2bm6Y6+dmYyrjWfKmAVJRbPHttnt7T2OUJSg8oThBBe3FKTq5O1i5Vba+cjHP/QR<br>
YLZtumRi9JdACs6VI6KcJbf7rvTd6NcOp3NNjog5NgjAhuVjTQAi5364QAlYO2q/<br>7KA/UlciI2jyYOu5oirFeOGLCo98rqeoIi+tf7whXT6z+cqCvcv0L/+5Ag0EYizS<br>0wEQAMi+pNlhNpgmUW8NGNKowBbj1HjZnSMNCeuJl4J0pit6WzF6ulLY0uuA9rEu<br>/
EO46tGU2iHu1QzLTmtpj480mm9FPLiJAv8dooKRCyjdkR9hw33iCZSI/u8pKI1i<br>+EbovJEVVvX2g5ci1cMQ7G8uRhC3GQ/63yBiWQ6OT+retorKFAnQY14S1i8r8eU1<br>gEuTOJsUU/J8XylrMOSSfkU5NnyE9fZzB07+1e8mrsXlq9qQhntcdCQ46q7f87vw<br>
iG5gzdXhy7tYpNHUd9syZyQMTYxxq4gaU8B9cHX5RUFqvwTR9WqBrv8qMeWNzZbg<br>IYnVCyS6f44lWtyopSUSw5aAOwYyYyIfIL9iym1rRJqReIUYA5fT5kSchbR9LUAI<br>Pfo/mZII8uCqirD+l3cDn9syiuATW5ubnVlCGWLFdbtZkrPmwU7n38Q7YrZK59o7<br>cHR1lQ5qwim5B0fF90Qo/
nRgwOk4fWNxhlwMCdUoeHtoAZSmuDPK8oDp6SqVdxaW<br>Qrsx2hnG6rKoclVMwTyEyNazcDaq9ZzMlIFRArw791J/lK3MtxnsXz3t2vonbEe1<br>mvblJ8celOd3NwZU1JDtJxSrNXgI1YJxtyu53m3rlWE7G9/s7JrEpS1fbyDux+Uo<br>dWc8LifnOD/AKKINNM0mJOyfcZa9wg1/rtyKMJ1zgHkZA25RABEBAAGJAiUEGAEI<br>
AA8FAmIs0tMCGwwFCQAbr4AACgkQiJt5aSvVtOONlBAAqbbaZ3+iVNxppqjxB3+Q<br>/v/olcD2OHBT7qRG5Lflkg/NucjxfF/6OGcRk2dX4kRxefEBG1B2gLsbrUKXnPCP<br>Z97ElV5OuMXOrWmYa8XYLLK3nee/b5wxAKQp60qhcD7qdmWigAnZXOLhZjeRsRym<br>QsC2Zqs4vRFKKgZ+SftMRIZ1C9lLXeaWvyZm+
szxUz6v82hpwVhHMirJCBa+DM/b<br>WXwOnlEF7j/8M1noMzUJaYXXOYVHjJSCJkWV4vvlVwKp1MNKdbYwq7jKHZxdxBMB<br>y9w4TReIlNYLgaGzo94rBA9MVF4OOniLjEHZKx303IOSFqZlnFtEAHZUGON6uVBC<br>40nISOGgLON2BKej8kRR+5u46m1x7mleeX0cUMLZGTvTNSfgedpCaGGcyWXRTJjh<br>Nl/
tEb6FJ5n2YAmNg7rx6EgGw7KcGzhLwcEIhess4zAjjOMYMXsG+xHe8jLMMA+v<br>dl/h62M+KKWne7zTraPvruPfSNazi4dZ+OQSGd1IU7THIQeLzPQy3xmaGODCT2Rb<br>rgG5a3UmG3beq8INyM32dTCPBdaylVEvHCFV7pLJQqV4rbsjI4y1Pj80Q1nKAWd6<br>KaEdm9RLst8dlGr/yqF2eKW6Anrq0BnIk2P+
1WUNT6kYw3uR54zEMJsEyHhGthHv<br>rBx9Eic2hgSnl4hB+jxtJJ0=<br>=anKA<br>-----END PGP PUBLIC KEY BLOCK-----<br><br></pre></blockquote></div></body></html>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)