Re: eMail voting (was GR: Hide Identities of Developers Casting a Particular Vote)

[Bill Allombert]

On Mon, Mar 07, 2022 at 06:41:54PM +, Thorsten Glaser wrote:
> >At the same time it relaxes the requirement that the secretary must
> >conduct a vote via email.  There are no current plans to move away from
> 
> This is a very bad idea.
> 
> Alternative solutions may
> • have accessibility problems (not work with lynx, for example)
> • require different transport (eMail can be done in batches)
> • be tricky to do with PGP signatures (and substituting web-ish
>   logins has its own kind of trouble (not least with lynx compat))
> • require more on the system, especially if it does not work with
>   lynx (such as heavy-weight UI with JS-capable browsers)
> • be more easy to filter (think countries’ web firewall) than eMail
> • have age requirements (many web services exclude minors for no
>   good reason)

The main reason we should stick with email is that so far every
Debian developpers has agreed to communicate within Debian by email
when joining. Moving to another system would be potentialy divisive with
little benefit.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

eMail voting (was GR: Hide Identities of Developers Casting a Particular Vote)

[Thorsten Glaser]

>At the same time it relaxes the requirement that the secretary must
>conduct a vote via email.  There are no current plans to move away from

This is a very bad idea.

Alternative solutions may
• have accessibility problems (not work with lynx, for example)
• require different transport (eMail can be done in batches)
• be tricky to do with PGP signatures (and substituting web-ish
  logins has its own kind of trouble (not least with lynx compat))
• require more on the system, especially if it does not work with
  lynx (such as heavy-weight UI with JS-capable browsers)
• be more easy to filter (think countries’ web firewall) than eMail
• have age requirements (many web services exclude minors for no
  good reason)

Please stick to eMail. Debian is currently a solid rock in not
jumping to the latest tech without thought… mostly, anyway.

Thanks in advance,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]

[Stéphane Glondu]

Le 26/02/2022 à 23:22, Don Armstrong a écrit :
>> I plan to look at least at belenios is voting by email is no longer
>> required. My plan is to run at least a small test to see if people
>> like it or not. I could maybe also run a larger poll. But we'll see
>> about how we pick a different system, or not, later.
> 
> Looks interesting. I know (having hacked up devotee to make
> pocket-devotee) that the plumbing around these systems is complicated;

Should Belenios (of which I am upstream) be chosen, I think some
adaptations (and plumbing) will be needed.

In Debian, every voter has a GPG key... This could be leveraged to
simplify things while retaining other security properties.

In Belenios, the primary voting interface is web-based, but its design
allows for other interfaces. For example, there exists a command-line
tool to create ballots, that can be submitted by whatever means to an
election board.

There is also the notion of "trustee", a person who is in charge of
keeping a share of the secret key used to decrypt ballots. The Secretary
comes to mind, but ideally there should be several independent trustees
(maybe the Technical Committee?).

But maybe we should wait for the principle of secret ballots to be
adopted before discussing implementation details...


Cheers,

-- 
Stéphane

Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]

[Sam Hartman]

> "Don" == Don Armstrong  writes:

>> However, I don't think it should take a 3:1 super majority to
>> change how we collect votes.

Don> I don't want it to take a 3:1 majority to add additional
Don> methods (web based, I'm presuming), but I think not allowing a
Don> signed (and/or encrypted) emailed ballot to count should
Don> require a 3:1 majority. [

Okay, then I recommend that you work on a ballot option.
I agree with Pierre-Elliott that the constitution is not where we should
specify the details of how to vote.


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 Armstrong]

On Fri, 25 Feb 2022, Sam Hartman wrote:
> 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.

[...]

> However, I don't think it should take a 3:1 super majority to change
> how we collect votes.

I don't want it to take a 3:1 majority to add additional methods (web
based, I'm presuming), but I think not allowing a signed (and/or
encrypted) emailed ballot to count should require a 3:1 majority. [The
former potentially allows more valid voters to vote, the latter
potentially reduces who can vote.]

[...]

> 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.

Worst case, the secretary would just have to set up two voting systems,
and import the results from one system into the other. [Kind of a pain,
but at least until we have a few votes under our belts with a new
system, it seems warranted. If I'm wrong, and everyone prefers the new
system, and there are no (or acceptable few) e-mailed votes, a
constitutional amendment should be easy.]

[...]

> 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.

[...]

> 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.

The secretary would still have to run a vote to make a statement of the
day, so it might as well still require a supermajority. [Alternatively,
we could write in a self-deleting section which only required a majority
to remove its effect... but that seems complicated.]

On Sat, 26 Feb 2022, Kurt Roeckx wrote:
> I plan to look at least at belenios is voting by email is no longer
> required. My plan is to run at least a small test to see if people
> like it or not. I could maybe also run a larger poll. But we'll see
> about how we pick a different system, or not, later.

Looks interesting. I know (having hacked up devotee to make
pocket-devotee) that the plumbing around these systems is complicated;
I'd certainly love to see a solution which has a larger community
contributing to it.

-- 
Don Armstrong  https://www.donarmstrong.com

Fate and Temperament are two words for one and the same concept.
 -- Novalis [Hermann Hesse _Demian_]

Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]

[Holger Levsen]

On Wed, Feb 23, 2022 at 04:54:30PM -0800, Don Armstrong wrote:
> I propose the following amendment to this ballot option, which if
> rejected I propose as its own option:
> 
> modified   english/devel/constitution.wml
> @@ -266,7 +266,8 @@ earlier can overrule everyone listed later.
>
>  
>
> -Votes are cast in a manner suitable to the Secretary.
> +Votes are cast by email in a manner suitable to the Secretary.
> +  Non-email methods suitable to the Secretary may be used in addition to 
> e-mail.
>  The Secretary determines for each poll whether voters can change
>  their votes.
>
> 
> https://salsa.debian.org/don/webwml/-/commit/9bbc20fed6881fa5b239830cad0939b979bbe300
> 
> Rationale: e-mail should continue to be an option for casting votes even
> while alternative methods of casting ballots might also be allowed.

seconded.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

„Copyright is for losers ©™“ (Banksy)


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]

[Pierre-Elliott Bécue]

Kurt Roeckx  wrote on 26/02/2022 at 12:47:16+0100:

> On Fri, Feb 25, 2022 at 08:06:20AM -0700, 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.
>
> I plan to look at least at belenios is voting by email is no longer
> required. My plan is to run at least a small test to see if people like
> it or not. I could maybe also run a larger poll. But we'll see about
> how we pick a different system, or not, later.

Stéphane could really give you some insigihts, here.

I don't know if that's in the scope of this GR, but I'd expect the
technical choice of the voting system to not be constitutionally
defined. I'd expect the constitution to set some unavoidable
requirements, but not define the exact technical tool, which could be
set in a DEP.

Cheers,

-- 
PEB


signature.asc
Description: PGP signature

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Kurt Roeckx]

On Wed, Feb 23, 2022 at 02:44:10PM -0700, Sam Hartman wrote:
> > "Pierre-Elliott" == Pierre-Elliott Bécue  writes:
> 
> Pierre-Elliott> I sponsor the resolution quoted below.
> 
> I haven't gone and checked signatures, but unless someone's signature is
> bad or something, I think that gives us more than enough sponsors.

Yes, there are more then enough people, and all signature checks passed.
But I will need more time to properly process everything.


Kurt

Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]

[Kurt Roeckx]

On Fri, Feb 25, 2022 at 08:06:20AM -0700, 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.

I plan to look at least at belenios is voting by email is no longer
required. My plan is to run at least a small test to see if people like
it or not. I could maybe also run a larger poll. But we'll see about
how we pick a different system, or not, later.


Kurt

Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]

[Richard Laager]

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: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]

[Sam Hartman]

> "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

Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]

[Russ Allbery]

Don Armstrong  writes:

> I propose the following amendment to this ballot option, which if
> rejected I propose as its own option:

Just for clarity's sake for everyone following, since this process is now
a bit different, there is no longer a formal amendment process like this.
You just propose another ballot option directly.  Sam can amend his
proposal provided that all of the current sponsors agree, but that doesn't
require anyone else to make a formal amendment and it's unrelated to the
ballot options.

That doesn't change anything about how you proposed this, but it does mean
that the next steps are a tiny bit different than they were.  Sam can
indicate whether he intends to do that or not, and if not, you'll want to
propose a full ballot option (in other words, will probably want to
duplicate more of Sam's text or refer to the other option similar to how
Wouter did in the last GR).

-- 
Russ Allbery (r...@debian.org)  

Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]

[Don Armstrong]

I propose the following amendment to this ballot option, which if
rejected I propose as its own option:

modified   english/devel/constitution.wml
@@ -266,7 +266,8 @@ earlier can overrule everyone listed later.
   
 
   
-Votes are cast in a manner suitable to the Secretary.
+Votes are cast by email in a manner suitable to the Secretary.
+  Non-email methods suitable to the Secretary may be used in addition to 
e-mail.
 The Secretary determines for each poll whether voters can change
 their votes.
   

https://salsa.debian.org/don/webwml/-/commit/9bbc20fed6881fa5b239830cad0939b979bbe300

Rationale: e-mail should continue to be an option for casting votes even
while alternative methods of casting ballots might also be allowed.


-- 
Don Armstrong  https://www.donarmstrong.com

We cast this message into the cosmos. [...] We are trying to survive
our time so we may live into yours. We hope some day, having solved
the problems we face, to join a community of Galactic Civilizations.
This record represents our hope and our determination and our goodwill
in a vast and awesome universe.
 -- Jimmy Carter on the Voyager Golden Record


signature.asc
Description: PGP signature

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Sam Hartman]

> "Pierre-Elliott" == Pierre-Elliott Bécue  writes:

Pierre-Elliott> I sponsor the resolution quoted below.

I haven't gone and checked signatures, but unless someone's signature is
bad or something, I think that gives us more than enough sponsors.

--Sam

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Pierre-Elliott Bécue]

I sponsor the resolution quoted below.

Sam Hartman  wrote on 23/02/2022 at 18:19:20+0100:
> I propose the followiwng general resolution, which will require a 3:1
> super majority to pass.
> I'm seeking sponsors for this resolution.
>
> Rationale
> =
>
> During the vote for GR_2021_002o, 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.  There are no current plans to move away from
> email, although some members of the project want to explore
> alternatives.  If this proposal passes, adopting such an alternative
> would require sufficient support in the project but would not require
> another constitutional amendment.
>
> This proposal relies on the secretary's existing power to decide how
> votes are conducted. During discussion we realized that there is no
> mechanism to override a specific decision of the secretary, and the
> language allowing the project to replace the secretary is ambiguous.
>
> 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.
>   
>
>   
> [-In case of-]{+Appoint+} a [-disagreement between-]{+new 
> secretary. In the normal case ( 7.2) where+} the project
> leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary, 
> [-appoint a new secretary.-]{+this power of+}
> {+the developers is not used.+}
>   
>   {++}
> {+Override a decision of the project secretary or their+}
> {+delegate.+}
>
> {+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.+}
>
> {+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.+}
> 
>
> 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. The voting period is 2 weeks, but may be 
> varied by up
>to 1 week by the Project Leader. 
> 
>   
>
> @@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
>   
>
>   
> Votes are cast[-by email-] in a manner suitable to the Secretary.
> The Secretary determines for each 

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Sean Whitton]

On Wed 23 Feb 2022 at 10:19AM -07, Sam Hartman wrote:

> I propose the followiwng general resolution, which will require a 3:1
> super majority to pass.
> I'm seeking sponsors for this resolution.

I sponsor this resolution.  Thanks Sam!

> Rationale
> =
>
> During the vote for GR_2021_002o, 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.  There are no current plans to move away from
> email, although some members of the project want to explore
> alternatives.  If this proposal passes, adopting such an alternative
> would require sufficient support in the project but would not require
> another constitutional amendment.
>
> This proposal relies on the secretary's existing power to decide how
> votes are conducted. During discussion we realized that there is no
> mechanism to override a specific decision of the secretary, and the
> language allowing the project to replace the secretary is ambiguous.
>
> 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.
>   
>
>   
> [-In case of-]{+Appoint+} a [-disagreement between-]{+new 
> secretary. In the normal case ( 7.2) where+} the project
> leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary, 
> [-appoint a new secretary.-]{+this power of+}
> {+the developers is not used.+}
>   
>   {++}
> {+Override a decision of the project secretary or their+}
> {+delegate.+}
>
> {+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.+}
>
> {+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.+}
> 
>
> 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. The voting period is 2 weeks, but may be 
> varied by up
>to 1 week by the Project Leader.
> 
>   
>
> @@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
>   
>
>   
> Votes are cast[-by email-] in a manner suitable to the Secretary.
> The Secretary determines for each 

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Filippo Rusconi]

Greetings,

On Wed, Feb 23, 2022 at 10:19:20AM -0700, Sam Hartman wrote:



I propose the followiwng general resolution, which will require a 3:1
super majority to pass.



I'm seeking sponsors for this resolution.


I sponsor the resolution below.

Sincerely,
Filippo



Rationale
=

During the vote for GR_2021_002o, 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.  There are no current plans to move away from
email, although some members of the project want to explore
alternatives.  If this proposal passes, adopting such an alternative
would require sufficient support in the project but would not require
another constitutional amendment.

This proposal relies on the secretary's existing power to decide how
votes are conducted. During discussion we realized that there is no
mechanism to override a specific decision of the secretary, and the
language allowing the project to replace the secretary is ambiguous.

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.
 

 
   [-In case of-]{+Appoint+} a [-disagreement between-]{+new secretary. In 
the normal case ( 7.2) where+} the project
   leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary, [-appoint a 
new secretary.-]{+this power of+}
{+the developers is not used.+}
 
 {++}
{+Override a decision of the project secretary or their+}
{+delegate.+}

{+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.+}

{+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.+}


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. The voting period is 2 weeks, but may be 
varied by up
  to 1 week by the Project Leader.
   
 

@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
 

 
   Votes are cast[-by email-] in a manner suitable to the Secretary.
   The Secretary determines for each poll whether voters can change
   their votes.
 
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.
 necessary.

 The next two weeks are the polling period during which
 

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Bill Blough]

On Wed, Feb 23, 2022 at 10:19:20AM -0700, Sam Hartman wrote:
> 
> 
> I propose the followiwng general resolution, which will require a 3:1
> super majority to pass.
> I'm seeking sponsors for this resolution.
> 

I sponsor the resolution quoted below.


> Rationale
> =
> 
> During the vote for GR_2021_002o, 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.  There are no current plans to move away from
> email, although some members of the project want to explore
> alternatives.  If this proposal passes, adopting such an alternative
> would require sufficient support in the project but would not require
> another constitutional amendment.
> 
> This proposal relies on the secretary's existing power to decide how
> votes are conducted. During discussion we realized that there is no
> mechanism to override a specific decision of the secretary, and the
> language allowing the project to replace the secretary is ambiguous.
> 
> 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.
>   
> 
>   
> [-In case of-]{+Appoint+} a [-disagreement between-]{+new 
> secretary. In the normal case ( 7.2) where+} the project
> leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary, 
> [-appoint a new secretary.-]{+this power of+}
> {+the developers is not used.+}
>   
>   {++}
> {+Override a decision of the project secretary or their+}
> {+delegate.+}
> 
> {+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.+}
> 
> {+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.+}
> 
> 
> 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. The voting period is 2 weeks, but may be 
> varied by up
>to 1 week by the Project Leader. 
> 
>   
> 
> @@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
>   
> 
>   
> Votes are cast[-by email-] in a manner suitable to the Secretary.
>   

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Steve McIntyre]

I sponsor the resolution quoted below.

On Wed, Feb 23, 2022 at 10:19:20AM -0700, Sam Hartman wrote:
>
>
>I propose the followiwng general resolution, which will require a 3:1
>super majority to pass.
>I'm seeking sponsors for this resolution.
>
>Rationale
>=
>
>During the vote for GR_2021_002o, 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.  There are no current plans to move away from
>email, although some members of the project want to explore
>alternatives.  If this proposal passes, adopting such an alternative
>would require sufficient support in the project but would not require
>another constitutional amendment.
>
>This proposal relies on the secretary's existing power to decide how
>votes are conducted. During discussion we realized that there is no
>mechanism to override a specific decision of the secretary, and the
>language allowing the project to replace the secretary is ambiguous.
>
>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.
>  
>
>  
>[-In case of-]{+Appoint+} a [-disagreement between-]{+new secretary. 
> In the normal case ( 7.2) where+} the project
>leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary, 
> [-appoint a new secretary.-]{+this power of+}
>{+the developers is not used.+}
>  
>  {++}
>{+Override a decision of the project secretary or their+}
>{+delegate.+}
>
>{+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.+}
>
>{+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.+}
>
>
>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. The voting period is 2 weeks, but may be 
>varied by up
>   to 1 week by the Project Leader. 
>
>  
>
>@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
>  
>
>  
>Votes are cast[-by email-] in a manner suitable to the Secretary.
>The Secretary determines for each poll whether voters can change
>their votes.
>  
>@@ -371,8 +390,7 @@ 

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Russ Allbery]

Sam Hartman  writes:

> I propose the followiwng general resolution, which will require a 3:1
> super majority to pass.
> I'm seeking sponsors for this resolution.

I sponsor the resolution quoted below.

> Rationale
> =

> During the vote for GR_2021_002o, 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.  There are no current plans to move away from
> email, although some members of the project want to explore
> alternatives.  If this proposal passes, adopting such an alternative
> would require sufficient support in the project but would not require
> another constitutional amendment.

> This proposal relies on the secretary's existing power to decide how
> votes are conducted. During discussion we realized that there is no
> mechanism to override a specific decision of the secretary, and the
> language allowing the project to replace the secretary is ambiguous.

> 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.
>   

>   
> [-In case of-]{+Appoint+} a [-disagreement between-]{+new 
> secretary. In the normal case ( 7.2) where+} the project
> leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary, 
> [-appoint a new secretary.-]{+this power of+}
> {+the developers is not used.+}
>   
>   {++}
> {+Override a decision of the project secretary or their+}
> {+delegate.+}

> {+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.+}

> {+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.+}
> 

> 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. The voting period is 2 weeks, but may be 
> varied by up
>to 1 week by the Project Leader. 
> 
>   

> @@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
>   

>   
> Votes are cast[-by email-] in a manner suitable to the Secretary.
> The Secretary determines for each poll whether voters can change
> their votes.
>  

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Sam Hartman]

I wanted to give a diff from what I published as the second round to
what I formally proposed.
The changes should be removal of the text about putting secretary
decisions on hold and  some indentation fixes in the rationale.

@@ -40,22 +40,20 @@ Summary of Changes
outcome requires a 3:1 majority.  The chair of the technical committee
decides who conducts such votes.

[-5) Clarify that decisions of the secretary or their delegates can be put-]
[-on hold.-]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 
[-dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d.-]{+ed88a1e3c1fc367ee89620a73047d84a797c9a1d.+}
As of February [-13,-]{+23,+} 2022, this commit can be found at
[-https://salsa.debian.org/hartmans/webwml/-/commit/dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d-]{+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.
  

@@ -86,18 +84,6 @@ In the normal case ( 7.2) where+} the project


4.2. Procedure
[-@@ -198,9 +216,9 @@ earlier can overrule everyone listed later.-]
[-Delaying a decision by the Project Leader or their Delegate:-]

[--]
[-  If the Project Leader or their Delegate, {+the project secretary 
or-]
[-their delegate,+} or the Technical-]
[-  Committee, has made a decision, then Developers can override them-]
[-  by passing a resolution to do so; see-]
[-[-4.1(3).-]{+4.1(3), 4.1(4), and 4.1(8).+}-]

[-  If such a resolution is sponsored by at least 2K Developers,-]
[-  or if it is proposed by the Technical Committee, the resolution-]
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.

   Votes are taken by the Project Secretary. Votes, tallies, and
@@ -127,6 +113,3 @@ varied by up
  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.-]{++}

[-  The options on the ballot will be those candidates who have-]
[-  nominated themselves and have not yet withdrawn, plus None Of The-]


signature.asc
Description: PGP signature

GR: Hide Identities of Developers Casting a Particular Vote

[Sam Hartman]

I propose the followiwng general resolution, which will require a 3:1
super majority to pass.
I'm seeking sponsors for this resolution.

Rationale
=

During the vote for GR_2021_002o, 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.  There are no current plans to move away from
email, although some members of the project want to explore
alternatives.  If this proposal passes, adopting such an alternative
would require sufficient support in the project but would not require
another constitutional amendment.

This proposal relies on the secretary's existing power to decide how
votes are conducted. During discussion we realized that there is no
mechanism to override a specific decision of the secretary, and the
language allowing the project to replace the secretary is ambiguous.

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.
  

  
[-In case of-]{+Appoint+} a [-disagreement between-]{+new secretary. 
In the normal case ( 7.2) where+} the project
leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary, 
[-appoint a new secretary.-]{+this power of+}
{+the developers is not used.+}
  
  {++}
{+Override a decision of the project secretary or their+}
{+delegate.+}

{+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.+}

{+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.+}


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. The voting period is 2 weeks, but may be 
varied by up
   to 1 week by the Project Leader. 

  

@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
  

  
Votes are cast[-by email-] in a manner suitable to the Secretary.
The Secretary determines for each poll whether voters can change
their votes.
  
@@ -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