"Judit" == Judit Foglszinger <urbec@riseup.net> writes:
I propose a ballot option for the GR
"Hide Identities of Developers Casting a Particular Vote"
that makes the following changes to the constitution.
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.
So it's the proposed GR minus the changes
not directly related to introducing secret votes.
I ask for seconds aka sponsors for this Option.
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 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>+}
Even if you don't want to move toward some different voting system, do...
we really want to require a constitutional amendment if say the
"Martin" == Martin Michlmayr <tbm@cyrius.com> writes:
"Martin" == Martin Michlmayr <tbm@cyrius.com> writes:
Yes, I think 3) and 4) are much more important in hidden votes.
I think change 2 (not requiring email) makes the anonymous voting
efforts easier but is not a strict requirement.
So, if I were going to unbundle this, I'd first want to see changes 3)
and 4) approved before I'd be comfortable voting for 1, 2 and 6.
I'd definitely be interested in improvements to the rationale of my
ballot option to better explain why changes 3-4 are something you
probably want to approve before 1, 2 and 6.
I absolutely agree that these changes would be split into multiple
commits in a software project
I think they would be one merge request though, and if I were the one approving the merging, I'd want 3-4 in the first merge request if it
were split into two merge requests.
Suppose no other options are present. Judit's option wins, yours is
second, and NotA is third. A simplistic reading would mean, "merge
Judit's proposed changes in the constitution". However, more people
voted 3 and 4 above NotA -- Shouldn't they also be included? Do they warrant a separate GR now?
I believe that the combinatorics (putting each possible combination on the ballot) is the correct approach given our voting system and given the
range of possible opinions.
To see why, suppose there is a voter who is happy with private votes
provided that the secretary decisions can be overridden, but if secretary decisions cannot be overridden, they do not want private votes. If the
two votes are unbundled, that voter cannot vote their preference, and
their only option is to either add a new ballot option on one of the votes
to do both at once or vote both below NotA.
If all three options (secretary changes only, private vote only, secretary changes plus private vote) are on the same ballot, that voter can then accurately vote their opinion by putting the last above NotA and the
second below NotA. The point of using a clone-proof voting system is to allow us to capture preferences like that by feeling free to add
additional options to the ballot.
I completely agree with separating *unrelated* changes, but the whole
point of this discussion is that some folks believe the changes are
closely related, to the extent that one of the changes may not be
desirable unless the other one is made at the same time.
If this is right, Sam, let me politely ask you to unbundle. Not only due
to Martin's argument (the scar of "editorial changes" we all had to
endure and understand a little too late), but also to keep each of the choices as simple and clear as possible -- and to avoid
combinatorics. And even clarity!
Say, now that Judit added a ballot option that works targets only one of
your concerns (voter secrecy). This option does not consider 3 and 4.
Suppose no other options are present. Judit's option wins, yours is
second, and NotA is third. A simplistic reading would mean, "merge
Judit's proposed changes in the constitution". However, more people
voted 3 and 4 above NotA -- Shouldn't they also be included? Do they
warrant a separate GR now?
Or should the GR have now four options? (Sam's original, Sam's minus 3
and 4, Judit's original, and Judit's plus 3 and 4)
Right -- the voting system allows for this quite well. But it requires twisting each of the voters' minds around a set of sometimes convoluted changesets that might lead to fatigue. The practice of not bundling
leads to simpler texts and easier evaluation and understanding by those
not closely following the discussions.
Even if you don't want to move toward some different voting system, do
we really want to require a constitutional amendment if say the
secretary wanted to move voting to a salsa-authenticated website to make
it easier and more accessible to our members?
I propose a ballot option for the GR
"Hide Identities of Developers Casting a Particular Vote"
that makes the following changes to the constitution.
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.
So it's the proposed GR minus the changes
not directly related to introducing secret votes.
I ask for seconds aka sponsors for this Option.
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 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>+}
I propose a ballot option for the GR
"Hide Identities of Developers Casting a Particular Vote"
that makes the following changes to the constitution.
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.
So it's the proposed GR minus the changes
not directly related to introducing secret votes.
I ask for seconds aka sponsors for this Option.
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 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>+}
I propose a ballot option for the GR
"Hide Identities of Developers Casting a Particular Vote"
that makes the following changes to the constitution.
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.
So it's the proposed GR minus the changes
not directly related to introducing secret votes.
I ask for seconds aka sponsors for this Option.
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 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>+}
While I'm personally probably more worried about how calls for votes are disseminated than about how the voting mechanism itself works, the
proposed change feels like a slippery slope towards the possibility that
how voting happens becomes generally less well understood. Requiring a
GR to change the mechanism seems like a completely reasonable way to
both vet the proposed change, and ensure a maximum number of potential
voters understand what's changing.
"Russ" == Russ Allbery <rra@debian.org> writes:
<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.
I think it would be clearer to add "that" between "confirm" and "their":
I think it would be clearer to add "that" between "confirm" and "their":
{+ public, but developers will be given an option to confirm that their vote is included in the votes+} cast.
"Judit" == Judit Foglszinger <urbec@riseup.net> writes:
>> I think it would be clearer to add "that" between "confirm" and
>> "their":
>>
>> {+ public, but developers will be given an option to confirm that
>> their vote is included in the votes+} cast.
Judit> I agree. It makes this option diverge a bit from the Option
Judit> A it was forked from, but since the meaning is not changed it
Judit> should be fine.
Should I adopt the change as well or does it only make sense for ballot option 2?
"Judit" == Judit Foglszinger <urbec@riseup.net> writes:
>> I think it would be clearer to add "that" between "confirm" and
>> "their":
>>
>> {+ public, but developers will be given an option to confirm that
>> their vote is included in the votes+} cast.
Judit> I agree. It makes this option diverge a bit from the Option
Judit> A it was forked from, but since the meaning is not changed it
Judit> should be fine.
Should I adopt the change as well or does it only make sense for ballot option 2?
"Kurt" == Kurt Roeckx <kurt@roeckx.be> writes:
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 45:49:09 |
| Calls: | 6,710 |
| Calls today: | 3 |
| Files: | 12,243 |
| Messages: | 5,354,246 |
| Posted today: | 1 |