Hi.
Here's an updated proposal based on discussion so far.
The changes were the ones I said I'd make Thursday:

1) include secretary decisions in the list of decisions that can be put
on hold.

2) Attempt to address Don's concerns regarding independent verification
of the tally and verification by individual developers that their votes
are counted.

The language around allowing individual developers to verify their votes
is a bit awkward.
Today as I understand it, you don't receive a vote hash if your GPG key
doesn't support encryption.
I didn't want to encode this in the constitution one way or another, so
I phrased things the way I did.

I'll send a diff of changes in the next message.


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.

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.
As of February 13, 2022, this commit can be found at https://salsa.debian.org/hartmans/webwml/-/commit/dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d

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.</cite></p>
</li>

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

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

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

<h3>4.2. Procedure</h3>
@@ -198,9 +216,9 @@ earlier can overrule everyone listed later.</cite></p>
<p>Delaying a decision by the Project Leader or their Delegate:</p>

<ol>
<li>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 [-&sect;4.1(3).</li>-]{+&sect;4.1(3), &sect;4.1(4), and &sect;4.1(8).</li>+}

<li>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.</cite></p>
<p>
Votes are taken by the Project Secretary. Votes, tallies, and
results are not revealed during the voting period; after the
vote the Project Secretary lists all the votes {+cast in sufficient detail that anyone may verify the outcome of the election from the votes cast. The+}
{+ identity of a developer casting a particular vote is not made+}
{+ public, but developers will be given an option to confirm their vote is included in the votes+} cast. The voting period is 2 weeks, but may be varied by up
to 1 week by the Project Leader.
</p>
</li>

@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p>
</li>

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

<li>The next two weeks are the polling period during which
Developers may cast their votes. [-Votes in leadership elections are-]
[- kept secret, even after the election is finished.</li>-]{+</li>+}

<li>The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCYhK0kAAKCRAsbEw8qDeG dPnqAP4stNvkLpvEZXLU6xkGjG/CHR2/u6rpOnwWADGCtCrMbwD+LrjD9nleDWlg t/EWKo1jFpfnqVhK2nzupkgNJs1k9g8=p/AX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Here's a diff to the rationale section:

Rationale
=========

@@ -21,7 +20,7 @@ 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.

@@ -41,22 +40,28 @@ 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 [-030405434d040e14bbebebaeda64555b5c1ee16a.-]{+dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d.+}
As of February 13, 2022, this commit can be found at [-https://salsa.debian.org/hartmans/webwml/-/commit/030405434d040e14bbebebaeda64555b5c1ee16a-]{+https://salsa.debian.org/hartmans/webwml/-/commit/dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d+}

For convenience a word-diff of the changes is included below. In case
the diff differs from the commit, the commit governs.

----------------------------------------

And here's the set of patches in rev 2 on top of rev 1
@@ -216,9 +216,9 @@ earlier can overrule everyone listed later.</cite></p>
<p>Delaying a decision by the Project Leader or their Delegate:</p>

<ol>
<li>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 [-&sect;4.1(3).</li>-]{+&sect;4.1(3), &sect;4.1(4), and &sect;4.1(8).</li>+}

<li>If such a resolution is sponsored by at least 2K Developers,
or if it is proposed by the Technical Committee, the resolution
@@ -246,9 +246,9 @@ 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.-]{+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>

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCYhK1pwAKCRAsbEw8qDeG dGoFAQCx9kXDZLz4Fvvldmp1hptjtkaRtzztFzuM/my26Ei9kwEAgcOP7X4UNxNi 13Ri5YjI5B04z70pF5WFxosW2Ssf5wQ=wrNs
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I'm generally happy with this proposed text. Just a couple of pieces of feedback, one quite minor.

Sam Hartman <hartmans@debian.org> writes:

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

Maybe "mechanism" rather than "option"? Option implies to me that it
might be some sort of up-front choice the voter has to make.

More substantively, while I agree with being able to override the Project Secretary via GR, I'm less comfortable with being able to put Project
Secretary decisions on hold if the GR is sponsored by 2K developers. That feels like a potential procedural mess. Is there any way that we could do without that and only allow retroactive overrides, or in some other way
clarify just *what* happens if a secretarial decision is put on hold?

Here's the sort of situation that I'm worried about:

* Some GR is proposed and is discussed for a couple of weeks.
* Near the end of the discussion period, the Project Secretary says that
this vote requires a 3:1 majority.
* Some developers disagree and propose a GR to override that decision.
* That GR gets 2K sponsors.

Now, under this new text, the Project Secretary's decision is "put on
hold." However, the constitution requires that the Project Secretary
start a vote on the GR because its discussion period has ended. So what
does putting that decision on hold *mean*? Does it mean we hold the vote saying that it's a 1:1 majority?

This gets even murkier if the Project Secretary makes a decision that
isn't a binary choice. I don't think this specific scenario is likely,
but what if someone objects to the Project Secretary's one-line summaries
for a ballot and successfully puts that decision on hold? What does "on
hold" even mean in that sort of context?

I realize this is really an objection to 4.2.2.2 in general, which is kind
of a mess, but at least it's currently a mess that's largely external to
our voting process, affecting decisions elsewhere in the project. I'm
worried that putting decisions on hold in the context of votes risks
getting into weird procedural edge cases where we cannot reasonably
proceed with a vote due to a pending override but are constitutionally
required to proceed with the vote.

I think I'd rather restrict overrides in the specific case of the Project Secretary to not have the "on hold" provision, and absorb the potential complexity of having to re-run votes with different parameters if the
resulting GR is successful.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Russ" == Russ Allbery <rra@debian.org> writes:

If other people would like to see the option allowing secretary
decisions to be placed on hold removed, I will remove it.
The specific class of decisions that are related to the rest of the
proposal are unlikely to need to be placed on hold.

Russ> Maybe "mechanism" rather than "option"? Option implies to me
Russ> that it might be some sort of up-front choice the voter has to
Russ> make.

But it is an up-front choice today.
If you have an encryption subkey, you get to participate.
If you don't then you do not.
I used the word option specifically to capture that right now it is an
up-front choice.

Russ> Here's the sort of situation that I'm worried about:

Russ> * Some GR is proposed and is discussed for a couple of weeks.
Russ> * Near the end of the discussion period, the Project Secretary
Russ> says that this vote requires a 3:1 majority. * Some
Russ> developers disagree and propose a GR to override that
Russ> decision. * That GR gets 2K sponsors.

Russ> Now, under this new text, the Project Secretary's decision is
Russ> "put on hold." However, the constitution requires that the
Russ> Project Secretary start a vote on the GR because its
Russ> discussion period has ended. So what does putting that
Russ> decision on hold *mean*?

I guess the secretary would need to interpret the constitution. If I
were secretary, I'd say that the discussion is done, but that we cannot
hold the vote until the issue surrounding the super-majority is
resolved.
Another fine option would be to conduct the vote but to determine the
outcome later after the super majority is resolved.

I guess that since we've identified this particular conflict we could
resolve it explicitly one way or another.

I don't think no matter how hard we try we will be able to resolve all
the conflicts in the constitution, so I am more interested in making
sure there are mechanisms to interpret and build up experience over
time than to try and make sure things are unambiguous.




Unfortunately, even more than other decisions, project secretary
decisions are very often timely.

I agree that the specific class of decisions--decisions about how votes
are conducted--that contemplated the proposal of 4.1(8) are not timely
in this manner.
And so I'd be okay removing my change to make secretary decisions able
to be put on hold if that would gain broader support.

Unfortunately, I think that just moves the problem around.
Let's say there's no language talking about putting a decision on hold.
What do we do if someone overrides the decision about what super
majority is required ?
We're still left with a mess.

And if we decide to remove the language about being able to override the secrety entirely, in one of the situations where people really care, we
just end up in extra-constitutional territory fairly quickly.

IN other words, I think we are exposing and acknowledging mesiness that
was already inherent in the system. Even with things like calling for
the vote, I suspect that in practice a secretary would delay the vote
while there was a discussion in full swing about some secretary
decisions, text in the constitution not withstanding.

-----BEGIN PGP SIGNATURE-----

iHQEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCYhPWjQAKCRAsbEw8qDeG dFQKAPY2s5cFHzZa+sigcPaqu7L3Z8AyNETCRdgtWdX3oPHbAQCqhD1DJw+ohWsC 6NJ7cfGUrOaI0La7m+oEC7OMcr6ZAg==
=3owi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sam Hartman <hartmans@debian.org> writes:

"Russ" == Russ Allbery <rra@debian.org> writes:

Russ> Maybe "mechanism" rather than "option"? Option implies to me
Russ> that it might be some sort of up-front choice the voter has to
Russ> make.

But it is an up-front choice today.
If you have an encryption subkey, you get to participate.
If you don't then you do not.
I used the word option specifically to capture that right now it is an up-front choice.

Oh, I see. This is fine with me, then.

I don't think no matter how hard we try we will be able to resolve all
the conflicts in the constitution, so I am more interested in making
sure there are mechanisms to interpret and build up experience over time
than to try and make sure things are unambiguous.

I agree. I would prefer to err on the side of empowering the Secretary to
make decisions in the moment (we can always redo GRs if we have to), and
am only nervous because we may have created a situation where we have a deadlock the Secretary isn't empowered to break.

Unfortunately, I think that just moves the problem around.
Let's say there's no language talking about putting a decision on hold.
What do we do if someone overrides the decision about what super
majority is required ?
We're still left with a mess.

To me, the critical points are that:

1. We need to have some sort of deadlock-free, starvation-free path to
resolving questions about a vote and then running that vote.

2. There's a reasonable argument for some way for the developers as a
whole to overrule or replace a Project Secretary. Right now, there's a
specific weird edge case where the Project Leader appoints the
Secretary and the Secretary runs the election of the Project Leader
(and the votes for every overrule of the Project Leader), so in theory
two people could collaborate to put the project in a very awkward spot.

IN other words, I think we are exposing and acknowledging mesiness that
was already inherent in the system.

Yes. All of these problems are pre-existing, so maybe this is really a
topic for a different GR. This comes up here specifically only because a secret vote increases the required level of trust.

Even with things like calling for the vote, I suspect that in practice a secretary would delay the vote while there was a discussion in full
swing about some secretary decisions, text in the constitution not withstanding.

I suppose one possible narrow fix would be to amend A.3.1 to say that the
seven day limit is waived if Secretary decisions about the vote have been
put on hold.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

TL;DR: I propose to unbundle the idea of putting secretary decisions
on-hold from my proposal.
I believe that will resolve Russ's concern.

"Russ" == Russ Allbery <rra@debian.org> writes:

Russ> Yes. All of these problems are pre-existing, so maybe this is
Russ> really a topic for a different GR. This comes up here
Russ> specifically only because a secret vote increases the required
Russ> level of trust.

I find the idea that we should only make the changes necessary for
secret ballots in this GR compelling.
So, my plan in terms of what I propose will be to remove the text about
putting secretary decisions on hold.
I think we're both agreed that we are unlikely to need that for
overriding decisions about the voting system.

If someone else proposed a version with the text about putting secretary decisions on-hold, I'd sponsor it and depending on how some of the
corner cases we're talking about here get resolved, possibly rank it
above the version I'm proposing.

However, I'm trying to come up with something that appeals to the
broadest set of people who want secret ballots,
and I think that doesn't include the text about putting decisions on
hold.

Unless you're interested in debugging a version that does involve
putting secretary decisions on hold, stop reading here.

----------------------------------------

I've rearranged Russ's message significantly to focus on the open
issues.
Apologies if my cut&paste distorts meaning, although I tried to work
hard to avoid that.
Russ> I would prefer to err on the side of empowering the
Russ> Secretary to make decisions in the moment (we can always redo
Russ> GRs if we have to), and am only nervous because we may have
Russ> created a situation where we have a deadlock the Secretary
Russ> isn't empowered to break.

I think the secretary is always empowered to break a deadlock by their
power to interpret the constitution.


Russ> To me, the critical points are that:

Russ> 1. We need to have some sort of deadlock-free, starvation-free
Russ> path to resolving questions about a vote and then running that
Russ> vote.

I am not that concerned about deadlock-free, because I think that the
secretary will always find a way to break a deadlock.
However, your concern about starvation-free is one I share.
I'm imagining 2k developers not acting in good faith putting an endless
series of decisions on hold and blocking the entire process.


Russ> 2. There's a reasonable argument for some way for the
Russ> developers as a whole to overrule or replace a Project
Russ> Secretary. Right now, there's a specific weird edge case
Russ> where the Project Leader appoints the Secretary and the
Russ> Secretary runs the election of the Project Leader (and the
Russ> votes for every overrule of the Project Leader), so in theory
Russ> two people could collaborate to put the project in a very
Russ> awkward spot.

I think the changes we're making do make it easier to replace the
secretary if necessary.

>> Even with things like calling for the vote, I suspect that in
>> practice a secretary would delay the vote while there was a
>> discussion in full swing about some secretary decisions, text in
>> the constitution not withstanding.

Russ> I suppose one possible narrow fix would be to amend A.3.1 to
Russ> say that the seven day limit is waived if Secretary decisions
Russ> about the vote have been put on hold.

I think that removes a deadlock but not starvation.
I think that a secretary would be likely to make that decision
regardless of what the constitution says,
but I agree that change would improve things if secretary decisions can
be put on hold.

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCYhUE8QAKCRAsbEw8qDeG dEZmAPkB+Vdy+BGJ386BMdrQLFwKQ74n64RxEC83vaehaKJQvAEA8w/VjBT9zJVP GDYeDxJM4+GReM/PHAIOYd/lL0i5ZgQ=
=fs3Z
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)