Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]
On 2/25/22 09:06, Sam Hartman wrote: 2) In the General resolution system, in addition to the constitutional amendment, include a statement of the day asking the secretary to obtain sufficient project consensus before changing how voting works. This feels almost like a tautology of sorts... you're telling the Secretary to make good decisions. If (hypothetically at some point in the future) we don't trust the Secretary, we should do something about that. If the Secretary makes a bad decision, we have mechanisms to deal with that (and are actively improving those mechanisms here). This particular statement of the day doesn't seem to really be binding, and even if it is, "sufficient" is subjective. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification
On Thu, Feb 24, 2022 at 05:44:34AM +0700, Judit Foglszinger wrote:
> 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.
>
>
> 4.2. Procedure
> @@ -228,9 +246,10 @@ earlier can overrule everyone listed later.
>
>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.
> necessary.
>
> 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.-]{++}
>
Seconded.
--
Tiago
signature.asc
Description: PGP signature
Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification
* Judit Foglszinger: " Ballot option 2 - Merely hide Identities of Developers
Casting a Particular Vote and allow verification" (Thu, 24 Feb 2022 05:44:34
+0700):
I sponsor this option.
Like others said: changing the vote system should be proposed in a
separate GR.
> 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.
>
>
> 4.2. Procedure
> @@ -228,9 +246,10 @@ earlier can overrule everyone listed later.
>
>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.
> necessary.
>
> 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.-]{++}
>
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
pgpYUaT5eouJQ.pgp
Description: Digitale Signatur von OpenPGP
Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification
On 2022-02-23 17 h 44, Judit Foglszinger wrote:
> 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.
>
>
> 4.2. Procedure
> @@ -228,9 +246,10 @@ earlier can overrule everyone listed later.
>
>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.
> necessary.
>
> 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.-]{++}
>
I sponsor this option.
As I said before, I think changing the way we vote (not by email) should
be done separately and shouldn't be bundled in this GR.
Thanks!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
OpenPGP_signature
Description: OpenPGP digital signature
Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification
Sam Hartman writes: > 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? Yes. 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. Bdale signature.asc Description: PGP signature
Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]
> "Don" == Don Armstrong writes: Don> Rationale: e-mail should continue to be an option for casting Don> votes even while alternative methods of casting ballots might Don> also be allowed. I'm supportive of a change here, and let's see if we can work out something that we both like. IN particular, I agree with the following: 1) As long as it make sense, we should continue to support email voting. 2) It needs sufficient project support to drop email voting. That shouldn't be something the secretary does all on their own. I'm sure Kurt wouldn't, but I also understand the desire to write these things down. However, I don't think it should take a 3:1 super majority to change how we collect votes. Whether I can vote by email just isn't as important as the DFSG, , our commitment to our users and free software, or the separation between DPL and DAM to me, or the idea that I can never be forced to do Debian work. I suspect that it would take a GR to change how we conduct votes, but I'd prefer not even to require that. If someone leads a discussion that reaches a rough consensus that some other voting system is good enough, I don't see why we'd need to have a GR at that point. I think there are two reasons why we might want to adjust our voting. First, there's the anonymous voting systems people have been talking about. I personally don't care about that, but I also don't want to add stop energy to the work of others. The second is that a number of developers do have trouble voting. In past elections where some parties wanted to strongly encourage voting we've seenn people write software to help developers fill out ballots. Now, I admit that in the instance I'm thinking of, a significant chunk of the motivation appeared to be political. But I've certainly helped other Debian developers cast their ballots. Even for people who do regular packaging work, getting GPG working in a mainly Windows or gmail mail flow is a pain and is not easy. And sure, while going through NM, obviously these people did have some solution to generate GPG signed mail regularly. But it's not clear that participating in one election is enough of a motivation to get that all working again. And yes, I agree with you that a lot of the ways I personally would work on fixing that problem would still make it easy to accept email ballots. In Debian we've generally embodied the principle that those doing the work get significant latitude in how the work gets done. To me, mandating email voting in the constitution is us telling the secretary how to do their job, potentially ruling out options that make their work harder and are demotivating. It also means that we need more bureaucracy for change. So, I'm wondering whether it would be enough to make it clear that changing the voting system beyond doing what we do for DPL discussions requires adequate project consensus. I'm thinking something along the lines of: 1) Update the rationale 2) In the General resolution system, in addition to the constitutional amendment, include a statement of the day asking the secretary to obtain sufficient project consensus before changing how voting works. I'd be happy to draft text for those two items if that would address your concern without creating a 3:1 super majority to change how we conduct voting. --Sam signature.asc Description: PGP signature
