Re: Draft proposal for resolution process changes

[Russ Allbery]

Karsten Merker  writes:

> On the other hand I see two issues in the current provision as a matter
> of principle:

> a) The constitution explicitly allows changing a vote during the
>voting period, so there is the possibility of convincing
>another member to change their already cast vote before the
>voting period ends.  From a formal point of view this means
>that there is no way to determine "if the outcome is no longer
>in doubt" before the regular voting period has ended, unless
>each member has declared that they will not change their vote
>anymore (which is equivalent to the process in my phrasing
>proposal above).

I agree this is true, and a vote could end prematurely in that sense with
this constitutional provision, when someone might still change their mind.

The main reason why this doesn't bother me in the context of the TC is
that because the TC is small and has a lighter-weight process, so it's
easy for them to correct this outcome by simply running another vote.  If
the vote ends and reaches a close conclusion and then someone changes
their mind, they can just re-propose the same question and hold another
vote and get a different outcome.

This doesn't work as well for developer GRs which require a ton more
effort on everyone's part and therefore are rare and involve a lot of
machinery.  In that case, we clearly need a fixed voting period to avoid
this sort of ambiguity.  But taking votes in the TC is routine business
and should happen all the time, so there should be a low bar to just
starting a new one (and that's also why they benefit from being able to
end votes quickly).

> b) The second concern that I have with the "majority party" (for lack of
>a better term) being able to shorten the voting period without
>consent from the other members is that it under certain circumstances
>allows removing the ability of other members to cast a dissenting
>vote with the argument "it wouldn't make a difference anyway".

>This could happen if a "dissenter" can cast their vote within the
>regular one-week period but not directly at the beginning and the
>voting period gets declared closed after a day or two because
>"further votes wouldn't make a difference".
>  
>Having the non-winning votes represented in the result is a basic
>element of democracy and is important for assessing the result.  For
>example if somebody is pondering over starting a GR after a TC
>decision it can make quite a bit of a difference whether the decision
>has been taken unanimously or whether it has been nearly a 50:50
>decision.

I largely agree with this but don't think this provision harms this
process in the specific context of the TC.

TC votes aren't taken with software that stops people from voting.
Instead, each member mails their signed ballot to the public mailing list.
That means that people can keep sending votes to the mailing list even
after the constitution says the vote is over, and those votes can be
counted by anyone who is tracking the exact vote outcome (for transparency
or any other reason).

I think this is a good argument for the TC to include any late-arriving
votes up to one week in any official results they post, but the
constitution doesn't prevent that, and since there isn't an official place
to publish such things, I'm not sure there's a need for the constitution
to require it.

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

Re: Draft proposal for resolution process changes

[Russ Allbery]

Felix Lechner  writes:

> Thank you for your lengthy and thoughtful reply. Sorry if it seems
> like I hijacked your thread.

No, no, this is great.  The whole point is to have an open discussion.
Thank you very much for your thoughtful message!  I think you're raising
some very interesting issues that are worth discussing.

I'm about to write a lot about philosophy and my personal opinions, so I
do want to say up-front that I don't think anyone has to agree with my
opinions about this (or about anything else in Debian for that matter) to
support the change that I'm proposing.  I've attempted to keep that
philosophy out of the proposal itself.  My goal is a proposal that anyone
can support as long as they agree that:

* We currently need an explicit and clearly-specified decision-making
  process for the Technical Committee and the Developers via General
  Resolution.
* The current systems for both are confusing and somewhat unclear, and
  have loopholes that have caused frustration and perceptions of
  unfairness in the past.
* This proposal is an incremental improvement in clarity and fairness
  without losing any valuable properties of the existing systems.

The one trade-off decision that I'm explicitly making is that, given the
past problems and complaints about issues with vote timing, I've made the
timing of votes less flexible in order to make them more predictable.

That being said, I'll now dive into my own personal philosophical
opinions.

> On Tue, Sep 28, 2021 at 1:04 PM Russ Allbery  wrote:

>> I'm reading this as another message of support for a tied vote in the
>> TC to result in an outcome of further discussion or to automatically
>> set off a GR.  Let me know if I misunderstood.

> My point was broader. I envision nothing "automatic" but would leave it
> instead to the TC Chair, in a living process, to precipitate an outcome
> that survives public scrutiny and even outcry.

My counter-argument is that we have concrete past experience with this
approach and we didn't enjoy the experience.  All sides felt like the
process led to procedural maneuvering and uncertainty that created a lot
of pain and hurt.

My goal for the TC section is to make explicit the rules around ballot
construction and how a proposal comes to a vote.

The process I'm proposing arguably favors the opposite side from my own in
the TC decision that primarily prompted this change and would have
prevented the process that indeed happened.  By this, I don't mean to
imply that the decisions at the time were wrong given the situation and
what we knew at the time (I think the situation was complex and I don't
want to take a position on that at all).  But with the benefit of a few
years of hindsight and watching subsequent GRs, I think a simpler process
with clearer rules and less flexibility would have had a better social
outcome for the project.

One of the significant problems at the time was that the constitution
specified almost nothing about how TC votes were started, and we were
unable to reach consensus on that in the middle of a contentious debate
because the procedural issues and the substantitive issues weren't
emotionally separable (at least for me, and I think I'm not alone).  This
is the whole point of having a process written down in advance, and in the
absence of any specific issue in mind: it lets us establish agreement on
the process without being in the heat of a specific disagreement, and then
fall back on that process agreement when trying to navigate a tricky
decision.

I find having an explicit process to use as a structure for navigating a
disagreement to be calming and supportive.  It makes me feel like I have
firm ground under my feet and space to think when I know procedurally what
I can and can't do in order to argue my perspective.

> Your concerns about tactical voting may be better handled by
> observers—such as the press, or fearless advocates of transparency like
> Adrian—while the process unfolds.

Addressing tactical voting via transparency only works if the people who
are voting tactically are likely to change their behavior because of that
transparency.  I do not believe this is true.  In a system that creates
incentives for tactical voting, I don't believe people who then vote
tactically are doing anything wrong, and therefore they have no reason to
fear transparency and have no reason to change their behavior regardless
of the opinions of observers.

The problem with tactical voting is technical: it makes your voting system
less likely to produce a fair outcome, where fair has a specific technical
definition based on the mapping of preferencs of voters to outcomes.  My
goal in avoiding tactical voting is not that I think tactical voting is
somehow unethical (I don't believe it is), but that it represents a lost
opportunity for a better system (at least up to the limits of Arrow's
theorem).

> For the writer of a constitution, fear weakens the document's intuitive
> appeal, however imprecise 

Re: Draft proposal for resolution process changes

[Russ Allbery]

Timo Röhling  writes:

> What do you think of the following:

>  6. If a vote is canceled later than 13 days after the original
> proposal, the mandatory vote will be postponed and start 24 hours
> after the time of cancellation. Until then, no one may call for
> another vote.

Oh, I like that much better.  I now have:

   6. If a vote is canceled under point 6.3.1.4 later than 13 days after 
  the initial proposed resolution, the vote specified in point 6.3.1.5
  instead starts 24 hours after the time of cancellation. During that 
  24 hour period, no one may call for a vote.

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

Re: Draft proposal for resolution process changes

[Sam Hartman]

> "Felix" == Felix Lechner  writes:

Felix> The constitution's projection of hardened confrontation
Felix> entails a terrible reflexivity: A 3:1 supermajority leaves no
Felix> gray area. There is no gentle nudge and no room for
Felix> measurement. The maintainer was so wrong, fixing it required
Felix> the second-worst measure in the Debian universe. (Expulsion
Felix> being the most drastic.) No defeated maintainer will go to
Felix> bed that night. thinking "well I lost, but it was a close
Felix> call." I would like to give the system more wiggle room.

Felix, one of the things I've learned to value both from software and
from politics is the idea of incremental improvement.

I very much would love to find ways to avoid hardened conflict.
You can see that in my rationale for resigning from the TC, in my
comments on finding compasion, and in my comments on thoughts about
revising the structure of the TC.

And yet, I think those changes are going to be larger.
I'd love to see us accomplish them.
I'm struggling trying to write a note to debian-private asking how we
managed to turn down a path of conflict rather than a path of
cooperation.

But I think those larger changes will take time.
And I think Russ's changes will make the process more fair and will
remove some potential obstacles for making those larger changes in the
future.

If I commit to continuing to work toward building a Debian with more
compassion and cooperation and less conflict, would you join me in that
work later and not stand in the way of this incremental improvement?

Re: Draft proposal for resolution process changes

[Timo Röhling]

* Russ Allbery  [2021-09-28 09:04]:

6. If voting is started prior to two weeks after the original proposal
   via a call for a vote by a member of the Technical Committee, but
   another member of the Technical Committee objects more than two
   weeks after the original proposal but before the vote completes, the
   vote is still canceled. All members of the Technical Committee are
   then given 24 hours to add new ballot options or modify or withdraw
   the ballot options they have proposed. During this period no one may
   call for a vote. Following that 24 hour period, a new voting period
   automatically starts and cannot be canceled.


Basically, there is a scenario where the vote could be canceled but the
subsequent ensuing discussion period during which members can change their
ballot options is so short as to be unfair (some of the committee is
asleep) or unusable.


What do you think of the following:

 6. If a vote is canceled later than 13 days after the original
proposal, the mandatory vote will be postponed and start 24 hours
after the time of cancellation. Until then, no one may call for
another vote.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Draft proposal for resolution process changes

[Felix Lechner]

Hi Russ,

Thank you for your lengthy and thoughtful reply. Sorry if it seems
like I hijacked your thread.

On Tue, Sep 28, 2021 at 1:04 PM Russ Allbery  wrote:
>
> I'm reading this as another message of support for a tied vote in the TC
> to result in an outcome of further discussion or to automatically set off
> a GR.  Let me know if I misunderstood.

My point was broader. I envision nothing "automatic" but would leave
it instead to the TC Chair, in a living process, to precipitate an
outcome that survives public scrutiny and even outcry.

I base that demand on public leadership on my own modest experience in
city government (on a library commission, including as Chair).

Your concerns about tactical voting may be better handled by
observers—such as the press, or fearless advocates of transparency
like Adrian—while the process unfolds. For the writer of a
constitution, fear weakens the document's intuitive appeal, however
imprecise the wording may seem. One cannot legislate thoughtful or
honest conduct. Our best hope is to inspire it.

> I think the constitution is the wrong foundational document to look to for
> the "minds of the governed."  The constitution is concerned primarily with
> the procedural details.  We have to spell them out somewhere so that we
> have a shared basis to make hard decisions in a way that we've previously
> agreed would be fair (even if we're on the losing side).

Why focus solely on the defeat? Is the "hard decision" not in fact a
win for the group?

The constitution's projection of hardened confrontation entails a
terrible reflexivity: A 3:1 supermajority leaves no gray area. There
is no gentle nudge and no room for measurement. The maintainer was so
wrong, fixing it required the second-worst measure in the Debian
universe. (Expulsion being the most drastic.) No defeated maintainer
will go to bed that night. thinking "well I lost, but it was a close
call." I would like to give the system more wiggle room.

Perhaps one day Joey Hess will tell me why he thought the constitution
was "a toxic document" when he left. [1]

[1] https://lists.debian.org/debian-devel/2014/11/msg00174.html

> The reason for the rework of the TC process in this proposal is precisely
> because the TC's decision-making capabilities previously partially broke
> down in ways that left a lot of damage behind, including accusations of
> unfairness.  This proposal would prevent the procedural circumstances that
> happened previously from happening again, in a way that I hope is more
> transparently fair and predictable than the current process.

Procedural safeguards do not build consensus—the all-elusive
project-wide goal the constitution so decidedly disavows. Maybe your
changes will not reduce the accusations of unfairness that prompted
them, and just silence them.

In another example of reflexivity, strong rules are a sign of
conflict. They are not needed—and rarely adopted—in peaceful and
easy-going communities.

> My experience in multiple heated debates in
> Debian, and in similar problems in other governance debates and on-line
> communities, is that having good, clear, and previously-agreed process is
> exactly what creates the space for people to be gracious and collaborative
> even when they strongly disagree with the opinions of others.

Please do not read my response as second-guessing your experience. I
am simply using this "space ... to be gracious and collaborative even"
though I "strongly disagree with the opinions of others".

> But I think the net long-term effect is to reduce the
> temperature.

How has it worked out so far? Thanks!

Kind regards
Felix Lechner

Re: Draft proposal for resolution process changes

[Russ Allbery]

Sam Hartman  writes:

> However, I think we already have the complexity you are worried about:
> 4.2.1 permits both the DPL and the TC tto sponsor a resolution without
> additional developers.

> I think that it's not too hard to make this useful.
> Under section 6.3,
> say something like
> "When the Technical Committee proposes a general resolution to the
> project, it may delegate the authority to accept amendments and withdraw
> ballot options to one of its members."

> If the TC didn't choose to delegate such authority, it would presumably
> have to vote on amendments.

Good catch.  I have added the following clause to my draft:

7. Proposing a general resolution.

   When the Technical Committee proposes a general resolution or a ballot
   option in a general resolution to the project under point 4.2.1, it may
   delegate the authority to withdraw, amend, or make minor changes to the 
   ballot option to one of its members. If it does not do so, these 
   decisions must be made by resolution of the Technical Committee.

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

Re: Draft proposal for resolution process changes

[Russ Allbery]

Hubert Chathi  writes:
> On Mon, 27 Sep 2021 18:51:05 -0700, Russ Allbery  said:

>> A.3. Calling for a vote

> ...

>> 3. Minor changes to ballot options under point A.1.5 may be made up
>> until 24 hours before the call for a vote is issued. However, if they
>> are made after or within 24 hours of the end of the discussion period,
>> the Project Secretary must agree the change does not alter the meaning
>> of the ballot option...

> The "must" makes it sound like the Project Secretary is obligated to
> agree that any such proposed change doesn't alter the meaning, which I
> suspect is not what was intended.  Perhaps instead,

> However, if they are made after or within 24 hours of the end of the
> discussion period, and Project Secretary agrees that the change does
> not alter the meaning of the ballot option, the Project Secretary
> will allow 24 hours for objections before issuing the call for a
> vote.

Good catch.

I think your wording has another alternate meaning: such a change could be
made and if the Project Secretary *doesn't* agree that it does not alter
the meaning, the change is still made but there's then no waiting period.
I now have this:

3. Minor changes to ballot options under point A.1.5 may not be made after
   or within 24 hours of the end of the discussion period unless the
   Project Secretary agrees the change does not alter the meaning of the
   ballot option and (if it would do so) warrants delaying the vote. The
   Project Secretary will allow 24 hours for objections after any such
   change before issuing the call for a vote.

which I think fixes the problem without ambiguity.

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

Re: Draft proposal for resolution process changes

[Hubert Chathi]

On Mon, 27 Sep 2021 18:51:05 -0700, Russ Allbery  said:

> A.3. Calling for a vote

...

> 3. Minor changes to ballot options under point A.1.5 may be made up
> until 24 hours before the call for a vote is issued. However, if they
> are made after or within 24 hours of the end of the discussion period,
> the Project Secretary must agree the change does not alter the meaning
> of the ballot option...

The "must" makes it sound like the Project Secretary is obligated to
agree that any such proposed change doesn't alter the meaning, which I
suspect is not what was intended.  Perhaps instead,

However, if they are made after or within 24 hours of the end of the
discussion period, and Project Secretary agrees that the change does
not alter the meaning of the ballot option, the Project Secretary
will allow 24 hours for objections before issuing the call for a
vote.

Hubert

Re: Draft proposal for resolution process changes

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> I don't recall the "when the outcome is no longer in doubt"
Russ> provision having been a problem in the past, so I admit my
Russ> bias is towards fixing the wording but maintaining the current
Russ> process.  I'm not sure there's a need for a change.

I support this approach.  I think if at any point the outcome is no
longer in doubt assuming no future actions, the vote should terminate.

In regard to a couple of other issues that have been raised:

* I find Carsten's message about tactical voting compelling.  I had
  almost been convinced to support removing the casting vote from the
  TC, but I think the argument Carsten's raises is good.  So I support
  keeping the casting vote.


* With regard to the issue of the long corner case and a member
  objecting to a TC call for vote late in the process... I note that we
  have seen calls for vote used tactically within the TC.  I hope we
  want to avoid that in the future, and given that  we've already seen
  tactical calls for votes happen, we should focus on corner cases
  involving them.
  In the particular case of a tactical call for votes on the TC
  (systemd), this corner case would not have mattered.  Even so, I think
  it is worth the language to fix.

Re: Draft proposal for resolution process changes

[Russ Allbery]

Karsten Merker  writes:

> "Votes are decided by the vote counting mechanism described in A.6.  By
> default, the voting period lasts for one week.  Members may change their
> votes during the voting period.  The TC can - even after the voting
> period has started - declare the voting period to end earlier if all
> members of the TC agree to that."

This allows any member of the TC to force the voting period to take a week
even if they're a minority of one.  Maybe it doesn't matter that much
because a week isn't very long, but this still doesn't seem correct (and
isn't the current practice).  Or, less controversially and more commonly,
it means that if one TC member is unavailable for some reason, all votes
are forced to be a week long because they're not available to agree to
make it shorter.

I don't recall the "when the outcome is no longer in doubt" provision
having been a problem in the past, so I admit my bias is towards fixing
the wording but maintaining the current process.  I'm not sure there's a
need for a change.

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

Re: Draft proposal for resolution process changes

[Russ Allbery]

Felix Lechner  writes:

> For a committee that effectively appoints its own members, it is
> probably unwise to ask the Chair to resolve split votes except in the
> most trivial of cases. A general vote, on the other hand, would supply
> the broad democratic legitimacy needed to silence critics forever.

> When facing that monumental and often disproportionate alternative,
> some TC members may reconsider their votes. At least I would.

I'm reading this as another message of support for a tied vote in the TC
to result in an outcome of further discussion or to automatically set off
a GR.  Let me know if I misunderstood.

I thought about this some more this morning and my concern procedurally is
that this creates a significant incentive for tactical voting.
Specifically, suppose that the technical committee is debating some
topic.  Four members support option A, three members support option B, and
the final member would prefer further discussion to either of those
options.  There is a 7:1 majority on the committee for taking some action,
either A or B.

If we say that a tie vote either defaults to further discussion or
triggers a GR, the minority of one can vote for option B to force a tie
vote (even though that isn't their true position), which then forces their
desired outcome even though it's not the choice of the other members, or
forces a GR when there may be significant consensus on the TC (options A
and B may differ in only relatively minor matters of wording or timing).

This creates a different version of the sort of problem that this proposal
is designed to prevent.  To avoid this in the proposed alternate scheme,
someone in favor of option B would have to vote in favor of A, and it may
not be knowable in advance that this may be necessary.  The whole
situation becomes a mess.  In contrast, with a casting vote, the most that
the minority of one can do is force the decision to a casting vote,
leaving it to the Chair to decide what the correct outcome should be.  And
the Chair can make that decision in the presence of full information about
how everyone voted (so, for instance, may vote against their own previous
vote if it's obvious from the voting results that tactical voting
happened).

It's important to remember here that we cannot get into a casting vote
situation via an up/down vote on a single option.  There has to be a
consensus to do something (not further discussion) before this outcome is
possible.  In other words, casting votes only come into play if the TC has
already concluded that something proposal should pass and is deciding
between multiple options.

> More generally, foundational documents do not captivate the minds of the
> governed when laden with procedural details. Our constitution already
> shuns a common purpose with "It does not describe the goals of the
> Project" (which for some reason comes right after the more positive "The
> Debian Project is an association of individuals who have made common
> cause to create a free operating system."). In the current thread, I
> miss simple language as to whether the purpose of decisions is
> legitimacy or speed.

I think the constitution is the wrong foundational document to look to for
the "minds of the governed."  The constitution is concerned primarily with
the procedural details.  We have to spell them out somewhere so that we
have a shared basis to make hard decisions in a way that we've previously
agreed would be fair (even if we're on the losing side).

> I would rely on a simple popular vote when needed (GR, and perhaps
> elections) but otherwise leave the TC to its own devices—including the
> ability to overrule a maintainer with an absolute majority (not 3:1).
> The TC has over the years proven itself to be a trusted and transparent
> institution with good decision-making capabilities. We act better in
> groups and more wisely than as individuals, with or without rules.

The reason for the rework of the TC process in this proposal is precisely
because the TC's decision-making capabilities previously partially broke
down in ways that left a lot of damage behind, including accusations of
unfairness.  This proposal would prevent the procedural circumstances that
happened previously from happening again, in a way that I hope is more
transparently fair and predictable than the current process.

More generally, I would encourage everyone to not discount the merits of
having a clear process, even if it feels nit-picky and constraining to
specify one in advance.  My experience in multiple heated debates in
Debian, and in similar problems in other governance debates and on-line
communities, is that having good, clear, and previously-agreed process is
exactly what creates the space for people to be gracious and collaborative
even when they strongly disagree with the opinions of others.

If everyone feels they are treated fairly following rules that were known
in advance and aren't changing on the fly to suit the moment, it's easier

Re: Draft proposal for resolution process changes

[Felix Lechner]

Hi,

On Tue, Sep 28, 2021 at 6:24 AM Adrian Bunk  wrote:
>
> whenever there is no clear majority in the TC ...
> the TC should ... propose a GR instead

For a committee that effectively appoints its own members, it is
probably unwise to ask the Chair to resolve split votes except in the
most trivial of cases. A general vote, on the other hand, would supply
the broad democratic legitimacy needed to silence critics forever.

When facing that monumental and often disproportionate alternative,
some TC members may reconsider their votes. At least I would.

More generally, foundational documents do not captivate the minds of
the governed when laden with procedural details. Our constitution
already shuns a common purpose with "It does not describe the goals of
the Project" (which for some reason comes right after the more
positive "The Debian Project is an association of individuals who have
made common cause to create a free operating system."). In the current
thread, I miss simple language as to whether the purpose of decisions
is legitimacy or speed.

Personally, the latter seems inconsistent with Debian's releases,
which occur when the time is right. [1]

If a brief excursion is permitted in our community of programmers, I
have over the past three years dropped thousands of hilarious
conditionals [2] from Lintian—another expression of our common
rules—because they too often obscured the code's purpose. My
recommendation would be to reduce the complexity of the Constitution,
as well:

I would rely on a simple popular vote when needed (GR, and perhaps
elections) but otherwise leave the TC to its own devices—including the
ability to overrule a maintainer with an absolute majority (not 3:1).
The TC has over the years proven itself to be a trusted and
transparent institution with good decision-making capabilities. We act
better in groups and more wisely than as individuals, with or without
rules.

Thanks for reading!

Kind regards
Felix Lechner

[1] https://wiki.debian.org/ReleasePolicy
[2] 
https://salsa.debian.org/lintian/lintian/-/commit/c36f898110dd83f57eeccf715e4908a3c0931752

Re: Draft proposal for resolution process changes

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> Procedurally, I don't believe we should automatically start a
Russ> GR because I think there's benefit to going through the normal
Russ> GR process.  For example, who is the proposer of the GR for
Russ> the purposes of making subsequent ballot option changes?  This
Russ> special type of GR would add a bunch of complexity that we'd
Russ> have to spell out, and I don't think it's worth it.
I agree with you that a GR should not automatically be triggered.  The
TC may want to word the GR differently, and it may be obvious that some
of the options on the TC ballot do not need to be proposed in a general
GR.


However, I think we already have the complexity you are worried about:
4.2.1 permits both the DPL and the TC tto sponsor a resolution without
additional developers.

I think that it's not too hard to make this useful.
Under section 6.3,
say something like
"When the Technical Committee proposes a general resolution to the
project, it may delegate the authority to accept amendments and withdraw
ballot options to one of its members."


If the TC didn't choose to delegate such authority, it would presumably
have to vote on amendments.

In many cases, I think individual TC members will find it easier to
simply propose a resolution themselves.  However, I think there are
cases where having the TC bring an issue to the project could lend
legitimacy to the decision making process and I would prefer not to
remove this power from the TC as part of this process.

--Sam

Re: Draft proposal for resolution process changes

[Russ Allbery]

"Theodore Ts'o"  writes:
> On Mon, Sep 27, 2021 at 06:51:05PM -0700, Russ Allbery wrote:

>> 4. The Project Leader has a casting vote. There is a quorum of 3Q. The
>>default option is "None of the above."

> Should this be, "unless specified elsewhere"?  

I think I confused matters by how I showed the changes.  This section is
specifically about GRs by the Developers.  In that situation, the default
option is always "None of the above."

>> 6.3. Procedure
>> 
>> 1. Resolution process.
>> 
>>The Technical Committee uses the following process to prepare a
>>resolution for vote:
>> 
>>1. Any member of the Technical Committee may propose a resolution.
>>   This creates an initial two-option ballot, the other option being
>>   the default option of "Further discussion." The proposer of the
>>   resolution becomes the proposer of the ballot option.

> Here the default option is "Further discussion" as opposed to "none of
> the above".  Is this intentional, or was this a historical artifact?

This was intentional.  I think that the default option for the TC is
different than that for a GR because the TC have a project obligation to
attempt to arrive at a decision, whereas it is more common for the
Developers in a GR to decide they don't want to say anything at all.

That said, I don't feel strongly about it.

> Also, as stated here in 6.3.1.1, it appears that any member of the TC
> may propose a resolution... on any subject they want?  I'm guessing the
> unstated presumption is this is related to a subject under discussion by
> the TC.  Should this be stated explicitly?

I can if folks feel the need, but I think it's fairly obvious in context
that this is constrained by the 6.1 Powers section slightly above this
section.  (For whatever it's worth, this is also not a change; the
existing text just says "A draft resolution or amendment may be proposed
by any member of the Technical Committee.")

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

Re: Draft proposal for resolution process changes

[Theodore Ts'o]

On Mon, Sep 27, 2021 at 06:51:05PM -0700, Russ Allbery wrote:
> 
> 4. The Project Leader has a casting vote. There is a quorum of 3Q. The
>default option is "None of the above."

Should this be, "unless specified elsewhere"?  

> 
> 6.3. Procedure
> 
> 1. Resolution process.
> 
>The Technical Committee uses the following process to prepare a
>resolution for vote:
> 
>1. Any member of the Technical Committee may propose a resolution.
>   This creates an initial two-option ballot, the other option being
>   the default option of "Further discussion." The proposer of the
>   resolution becomes the proposer of the ballot option.

Here the default option is "Further discussion" as opposed to "none of
the above".  Is this intentional, or was this a historical artifact?

Also, as stated here in 6.3.1.1, it appears that any member of the TC
may propose a resolution... on any subject they want?  I'm guessing
the unstated presumption is this is related to a subject under
discussion by the TC.  Should this be stated explicitly?

Thanks,

- Ted

Re: Draft proposal for resolution process changes

[Russ Allbery]

Richard Laager  writes:

> If I understand correctly, the updated GR process handles this
> differently, by extending the clock on changes and prohibiting such
> changes at "the last minute" (the end of the maximum discussion period).

Correct.

> That could be another option here, which would have the benefit of
> consistency. But the TC is a different situation than a GR, and they
> don't need to be exactly the same process.

Yes, and I couldn't figure out a way to use that approach and also allow
the TC to call for a vote whenever they're ready, which is the normal case
and which we don't want to rule out (we don't want every TC vote to have
to take two plus weeks).  The fix for the GR relies on having a fixed
schedule for when the vote will start that's known at any given moment.

One of the things I realized while drafting this is that the TC process
wants to override more than half of the regular process because a lot of
things work differently with a small group and no sponsorship
requirements, and it makes sense for them to just have their own process.
It's much easier for the TC to just vote further discussion if something
happens that they don't like, for example.

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

Re: Draft proposal for resolution process changes

[Russ Allbery]

Timo Röhling  writes:

> In this context,

> 6.3.1.3. If all ballot options are withdrawn, the process is canceled.

> is slightly ambiguous, as the default option is technically also a ballot
> option. Maybe change it to "If all proposed ballot options…"?

> For that reason, I would also change 6.3.1.2 to read "Any member of the
> Technical Committee may *propose* additional ballot options", which
> also makes it consistent with the phrasing in A.1.1.2

Thank you!  I've made both of those fixes.  6.3.1.3 now reads:

   3. If all ballot options except the default option are withdrawn, the
  process is canceled.

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

Re: Draft proposal for resolution process changes

[Timo Röhling]

* Russ Allbery  [2021-09-28 09:24]:

Thank you, this is a good idea.  The advance reference to withdrawal is
exactly why I didn't do that originally, but on further reflection I think
it's fine.  I now have as A.1.7:

7. The default option has no proposer or sponsors, and cannot be amended
  or withdrawn.

and dropped the point that was A.2.4.

In this context,

6.3.1.3. If all ballot options are withdrawn, the process is canceled.

is slightly ambiguous, as the default option is technically also a ballot
option. Maybe change it to "If all proposed ballot options…"?

For that reason, I would also change 6.3.1.2 to read "Any member of the
Technical Committee may *propose* additional ballot options", which
also makes it consistent with the phrasing in A.1.1.2

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Draft proposal for resolution process changes

[Richard Laager]

Thank you for the clarifications.

On 9/28/21 11:04 AM, Russ Allbery wrote:

3. Another TC member calls a vote, possibly immediately after making some
   last minute change to the ballot (which is allowed).
If I understand correctly, the updated GR process handles this 
differently, by extending the clock on changes and prohibiting such 
changes at "the last minute" (the end of the maximum discussion period). 
That could be another option here, which would have the benefit of 
consistency. But the TC is a different situation than a GR, and they 
don't need to be exactly the same process.


I don't have strong feelings on this detail either way.

--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Re: Draft proposal for resolution process changes

[Russ Allbery]

The Wanderer  writes:

> As a possibility to consider, what about folding this into A.1.7? That
> already states that the default option cannot be amended, which likewise
> would seem to follow from the fact that it has no proposer and thus no
> one to make or accept amendments.

> Something like "The default option has no proposer or sponsors, and as
> such, can neither be amended nor withdrawn." would seem to convey all
> aspects in one concise sentence - although it does have the downside
> that it would be referring to withdrawal prior to the section where
> withdrawal is discussed.

Thank you, this is a good idea.  The advance reference to withdrawal is
exactly why I didn't do that originally, but on further reflection I think
it's fine.  I now have as A.1.7:

7. The default option has no proposer or sponsors, and cannot be amended
   or withdrawn.

and dropped the point that was A.2.4.

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

Re: Draft proposal for resolution process changes

[Russ Allbery]

Russ Allbery  writes:

> The scenario where this matters is this:

> 1. Vote starts.  There is some controversy and discussion for a week and a
>half.
> 2. 12 days into the voting period one TC member is away or ill or
>otherwise unable to immediately respond.
> 3. Another TC member calls a vote, possibly immediately after making some
>last minute change to the ballot (which is allowed).
> 4. By the time the TC member who would object returns, either the timing
>for the mandatory vote has elapsed or, were the vote canceled, the
>mandatory vote would start again within a matter of hours.

A mischosen word made that hopelessly confusing.  Point 1 is supposed to
start with "Proposal starts."

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

Re: Draft proposal for resolution process changes

[Russ Allbery]

"Dr. Bas Wijnen"  writes:
> On Tue, Sep 28, 2021 at 04:11:44PM +0200, Karsten Merker wrote:

>> In case there should be consensus about requiring the TC chair to
>> provide a casting vote in case of a tie, this would IMHO require
>> changing the wording of clause 6.3.2.

> I agree that if we keep the casting vote intact, it needs to be a must
> in order to ensure the TC will always decide something. However, I agree
> with Adrian that it would be better to instead turn the decision into a
> GR in such a case.

My understanding of what you're proposing here is a boarder change where
the TC does not have a casting vote at all for any vote (not just for the
edge case of a vote to override a maintainer decision by the Chair), and
that if the Schwartz set has two or more members, the result is to not
make a decision?

Procedurally, I don't believe we should automatically start a GR because I
think there's benefit to going through the normal GR process.  For
example, who is the proposer of the GR for the purposes of making
subsequent ballot option changes?  This special type of GR would add a
bunch of complexity that we'd have to spell out, and I don't think it's
worth it.  Given that any Developer can start a GR following such an
outcome, I think the way to achieve this if this is what we want is to
declare further discussion the winner in any ambiguous vote that would
otherwise be decided by casting vote and then leave it open whether
someone chooses to start a GR.

But before we decide this, it's worth remembering that the only way this
can arise is if the TC is split between two non-default decisions (so
there is consensus to make *some* decision), and the question (unlike the
one where the TC ended up split over init systems) may be urgent.  A GR
takes a *minimum* of three more weeks, and most likely would take closer
to five.

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

Re: Draft proposal for resolution process changes

[Russ Allbery]

Karsten Merker  writes:
> Am Mon, Sep 27, 2021 at 06:51:05PM -0700 schrieb Russ Allbery:

>> 7. [...] There is no casting vote. If there are multiple options with no
>>defeats in the Schwartz set at the end of A.6.8, the winner will be
>>chosen from those options by lot, via a mechanism chosen by the Project
>>Secretary.

> What ist the meaning of the term "chosen by lot"?  My dictionary
> doesn't explain the expression in the context of a vote but only
> in the context of a piece of land, which doesn't make sense here.

Apologies, it's a term of art in voting system discussion in English, but
it's unfriendly to people not familiar with that.  I've changed this to
"the winner will be randomly chosen from those options."

>>When the Technical Committee votes whether to override a Developer
>>who also happens to be a member of the Committee, that member may
>>not vote (unless they are the Chair, in which case they may use only
>>their casting vote).

> What is the reason for having a special rule for the chair compared to
> the other members of the TC in case of having to abstain from the vote?

I went into this a bit more in a different message just now, but the short
answer is that a voting system should always have a well-defined outcome
or some other process to handle cases where there are multiple winners but
there can only be one winner.

>> 2. Details regarding voting.
>>
>>Votes are decided by the voting counting mechanism described in A.6.
>>The voting period lasts for one week or until the outcome is no longer
>>in doubt, whichever is shorter. Members may change their votes.

> How can be determined that the outcome is no longer in doubt before the
> voting period ends if members can change their vote at any point in time
> until the end of the voting period?

Yeah, this wording bugs me too.  It's pre-existing and I didn't try to fix
it, but we probably should.  The simplest fix (including a typo fix for
the first line) would be:

Votes are decided by the vote counting mechanism described in A.6.
The voting period lasts for one week or until the outcome is no longer
in doubt assuming no members change their votes, whichever is shorter.
Members may change their votes until the voting period ends.

It's still a bit awkward.  Better phrasing is welcome.  I'm not sure I see
a better fix; we do want members to be able to change their votes, but we
don't want every vote to have to take a full week.

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

Re: Draft proposal for resolution process changes

[Russ Allbery]

Richard Laager  writes:

> First off, thank you for working on this!

> On 9/27/21 8:51 PM, Russ Allbery wrote:

>> 6. If voting is started prior to two weeks after the original proposal
>>via a call for a vote by a member of the Technical Committee, but
>>another member of the Technical Committee objects more than two
>>weeks after the original proposal but before the vote completes, the
>>vote is still canceled. All members of the Technical Committee are
>>then given 24 hours to add new ballot options or modify or withdraw
>>the ballot options they have proposed. During this period no one may
>>call for a vote. Following that 24 hour period, a new voting period
>>automatically starts and cannot be canceled.

> Is this complexity necessary? If the vote was not called early, the vote
> would have started anyway on time and been uncancellable. And the
> objector did not object in time. (If the objector had objected prior to
> the normal starting time, we aren't in this scenario.) Why does someone
> get extra time to object in this case?

I went back and forth on this.  I can drop it if people don't think the
edge case is important enough.

The scenario where this matters is this:

1. Vote starts.  There is some controversy and discussion for a week and a
   half.
2. 12 days into the voting period one TC member is away or ill or
   otherwise unable to immediately respond.
3. Another TC member calls a vote, possibly immediately after making some
   last minute change to the ballot (which is allowed).
4. By the time the TC member who would object returns, either the timing
   for the mandatory vote has elapsed or, were the vote canceled, the
   mandatory vote would start again within a matter of hours.

Basically, there is a scenario where the vote could be canceled but the
subsequent ensuing discussion period during which members can change their
ballot options is so short as to be unfair (some of the committee is
asleep) or unusable.

In other words, what this provision is here for is that it provides a
significant disincentive for anyone to tactically start a vote at the last
minute to cut off the last day or two of discussion, possibly immediately
after making a ballot change.  Under this provision, someone who disagrees
can wait until the two weeks have passed and then object and the
discusssion period is effectively extended by 24 hours, which will
hopefully give everyone a chance to react regardless of time zones.

I admit that this is a very obscure edge case and it's unlikely to be
triggered.  I can drop it if people would prefer the simplicity and are
willing to live with that scenario on the grounds that everyone should get
their preferred options in reasonably far in advance of the known deadline
and last-minute changes to other people's options therefore shouldn't
matter all that much (and if they do, one can always vote further
discussion and start again).

We do need to say something about what happens if a vote is called before
the two-week deadline and then objected to after the two-week deadline,
since otherwise the rules are ambiguous.  We could say something simpler,
though, such as "An ongoing vote cannot be canceled if more than two weeks
have passed since the original proposal."

>> 2. Details regarding voting.
>> When the Technical Committee votes whether to override a Developer who
>> also happens to be a member of the Committee, that member may not vote
>> (unless they are the Chair, in which case they may use only their
>> casting vote).

> I know this is how it is now. But it's always seemed weird. If TC members
> cannot vote on overruling themselves, why does the chair get to (but only
> in the event of a tie)?

I think we need to avoid an undefined outcome, so if there is no casting
vote, we have to pick some other strategy for making the outcome defined.

The only alternatives that I can think of are picking the result randomly
among the Schwartz set with no defeats, or declaring further discussion
the winner, but both of those have problems.  (Or, I guess a third would
be to give a casting vote to someone outside the TC, like the DPL, but I'm
not sure if that additional complexity is worth it.)

I think the former is fine for selecting the chair; obviously both
candidates have support and I think a random choice is a reasonable
outcome of that ballot.  But choosing between two very technical decisions
at random just feels wrong to me.

The latter may sound more reasonable, but the problem is that the tie
could be between multiple options that are nothing like further
discussion, and both of which beat further discussion by substantial
margins, so the winner is then the least-favored option, which seems
backwards.  Maybe that's what we want, but that isn't obvious to me.

> Is this even meaningful? Presumably they would vote against overruling
> themselves, if there are such options. But it seems 

Re: Draft proposal for resolution process changes

[The Wanderer]

On 2021-09-28 at 11:44, Russ Allbery wrote:

> Gard Spreemann  writes:
> 
>> Russ Allbery  writes:
> 
>>> A.2. Withdrawing ballot options:
>>> 
>>> […]
>>> 
>>> 4. The default option cannot be withdrawn.
> 
>> This is the most minor of near-useless pedantic comments on my
>> part, but A.2.4 seems redundant: If only the proposer of a ballot
>> option may withdraw it (A.2.1), and the default option has no
>> proposer (A.1.7), then we don't really need a separate rule saying
>> that the default cannot be withdrawn.
> 
> Yes, I completely agree there's no technical need for this.  I
> included it anyway because it felt like it added some clarity and
> meant that the reader didn't have to chase the logic down through
> several other provisions to be sure.  There are a few other places
> like this in the text (mostly around repeating phrases) where I erred
> on the side of clarity rather than brevity.
> 
> I can certainly change this if people would prefer.  It's possible
> that I overcorrected for how tricky I find it to interpret the
> current wording.

As a possibility to consider, what about folding this into A.1.7? That
already states that the default option cannot be amended, which likewise
would seem to follow from the fact that it has no proposer and thus no
one to make or accept amendments.

Something like "The default option has no proposer or sponsors, and as
such, can neither be amended nor withdrawn." would seem to convey all
aspects in one concise sentence - although it does have the downside
that it would be referring to withdrawal prior to the section where
withdrawal is discussed.

(I'll note that I'm barely even a contributor, certainly not a DD, so my
voice here has significantly less relevance than might be ideal for
participation in such a discussion.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Draft proposal for resolution process changes

[Russ Allbery]

Gard Spreemann  writes:
> Russ Allbery  writes:

>> A.2. Withdrawing ballot options:
>>
>> […]
>>
>> 4. The default option cannot be withdrawn.

> This is the most minor of near-useless pedantic comments on my part, but
> A.2.4 seems redundant: If only the proposer of a ballot option may
> withdraw it (A.2.1), and the default option has no proposer (A.1.7),
> then we don't really need a separate rule saying that the default cannot
> be withdrawn.

Yes, I completely agree there's no technical need for this.  I included it
anyway because it felt like it added some clarity and meant that the
reader didn't have to chase the logic down through several other
provisions to be sure.  There are a few other places like this in the text
(mostly around repeating phrases) where I erred on the side of clarity
rather than brevity.

I can certainly change this if people would prefer.  It's possible that I
overcorrected for how tricky I find it to interpret the current wording.

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

Re: Draft proposal for resolution process changes

[Dr. Bas Wijnen]

On Tue, Sep 28, 2021 at 04:11:44PM +0200, Karsten Merker wrote:
> In case there should be consensus about requiring the TC chair
> to provide a casting vote in case of a tie, this would IMHO
> require changing the wording of clause 6.3.2.

I agree that if we keep the casting vote intact, it needs to be a must in order
to ensure the TC will always decide something. However, I agree with Adrian
that it would be better to instead turn the decision into a GR in such a case.

Thanks,
Bas

Re: Draft proposal for resolution process changes

[Pierre-Elliott Bécue]

Russ Allbery  wrote on 28/09/2021 at 03:51:05+0200:

> [Snip]
> This proposal was already sufficiently complex that it does not attempt to
> address the secret ballot.  I believe that should be a separate discussion
> and a separate GR since it's substantially orthogonal to this one.

Note that we discussed the secret ballot privately and I intend to make
a draft proposal after the GR for this Constitutional change.

--
PEB


signature.asc
Description: PGP signature

Re: Draft proposal for resolution process changes

[Adrian Bunk]

On Tue, Sep 28, 2021 at 01:38:48PM +0100, Simon McVittie wrote:
>...
> Also, I believe the rationale for this casting vote is the same as for
> the existence of a casting vote in general: to make sure that the TC is
> always able to make a decision, one way or another, and that there is
> never an unresolved situation where the outcome of the vote is "there is
> no decision".
>...

IMHO whenever there is no clear majority in the TC (let's say 3:1),
the TC should use its power under 4.2.1. to propose a GR instead
of making a decision.

Past TC casting vote decisions that come into my mind are systemd and
merged /usr. It would have been faster and less painful for the whole
project had such decisions started by involving the whole project
in a structured 2 week GR discussion followed by a democratic vote,
instead of having years of mess and bad blood after a TC-only decision.

> smcv

cu
Adrian

Re: Draft proposal for resolution process changes

[Simon McVittie]

On Tue, 28 Sep 2021 at 13:56:21 +0200, Karsten Merker wrote:
>   In this case the chair surely wouldn't vote to overrule
>   themselves as that would be a completely nonsensical behaviour,

The casting vote cannot be used to select an option that is not in the
Schwartz set (loosely: it can only be used to select an option that
could have won if it had one extra vote). Suppose the TC chair wants
to paint a bike shed green, but this is unacceptable for some reason,
and we have a vote among the TC members with these options:

R: overrule the TC chair: the bike shed must be red
B: overrule the TC chair: the bike shed must be blue
Y: overrule the TC chair: the bike shed must be yellow
FD: further discussion

If the TC membership (excluding the chair in this case) has voted
R = B > FD > Y, with some members preferring R > B and an equal number
preferring B > R, so that both R and B are in the Schwartz set, then the
chair is forced to use their casting vote to overrule themselves. They
can use the casting vote to choose whether the bike shed must be red or
blue, but they cannot choose to paint it green or yellow, because those
options were not in the Schwartz set.

Also, I believe the rationale for this casting vote is the same as for
the existence of a casting vote in general: to make sure that the TC is
always able to make a decision, one way or another, and that there is
never an unresolved situation where the outcome of the vote is "there is
no decision". Even if the chair is not placed in the bizarre situation
of choosing precisely how to overrule themselves, they should still be
stating a decision.

To put that another way, if the TC is voting on options R, B, Y and
Further Discussion, we would like the outcome to be either R, B, Y
or FD. It seems bad if the outcome can, in rare cases, be a strange
indeterminate state that is distinct from FD, but is also not R, B or Y.

> - There is an excemption for the chair in the rule about having
>   to abstain from the vote and the chair makes use of the casting
>   vote.

In this case, the TC has (narrowly) made a decision: namely, not to
overrule the chair.

> - There is no special excemption for the chair in the rule about
>   having to abstain from the vote, so the tie isn't resolved and 
>   as a result the TC doesn't overrule the chair.

In this case, the TC has not made any decision - we have not decided to
overrule the chair, we have not decided to decline to overrule the chair,
and we have not even decided on Further Discussion! Once we get to the
point of holding a vote, I don't think we want this to be procedurally
possible.

smcv

Re: Draft proposal for resolution process changes

[Andrey Rahmatullin]

On Tue, Sep 28, 2021 at 12:31:30PM +0200, Karsten Merker wrote:
> >When the Technical Committee votes whether to override a Developer who
> >also happens to be a member of the Committee, that member may not vote
> >(unless they are the Chair, in which case they may use only their
> >casting vote).
> 
> What is the reason for having a special rule for the chair compared to the
> other members of the TC in case of having to abstain from the vote?
Only the chair has the casting vote.
Also, this part hasn't changed from the current Constitution text.

> > 2. Details regarding voting.
> >
> >Votes are decided by the voting counting mechanism described in A.6.
> >The voting period lasts for one week or until the outcome is no longer
> >in doubt, whichever is shorter. Members may change their votes.
> 
> How can be determined that the outcome is no longer in doubt before the
> voting period ends if members can change their vote at any point in time
> until the end of the voting period?
This part hasn't changed from the current Constitution text either.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Draft proposal for resolution process changes

[Richard Laager]

First off, thank you for working on this!

On 9/27/21 8:51 PM, Russ Allbery wrote:

6. If voting is started prior to two weeks after the original proposal
   via a call for a vote by a member of the Technical Committee, but
   another member of the Technical Committee objects more than two
   weeks after the original proposal but before the vote completes, the
   vote is still canceled. All members of the Technical Committee are
   then given 24 hours to add new ballot options or modify or withdraw
   the ballot options they have proposed. During this period no one may
   call for a vote. Following that 24 hour period, a new voting period
   automatically starts and cannot be canceled.


Is this complexity necessary? If the vote was not called early, the vote 
would have started anyway on time and been uncancellable. And the 
objector did not object in time. (If the objector had objected prior to 
the normal starting time, we aren't in this scenario.) Why does someone 
get extra time to object in this case?



2. Details regarding voting.
When the Technical Committee votes whether to override a Developer who
also happens to be a member of the Committee, that member may not vote
(unless they are the Chair, in which case they may use only their
casting vote).


I know this is how it is now. But it's always seemed weird. If TC 
members cannot vote on overruling themselves, why does the chair get to 
(but only in the event of a tie)?


Is this even meaningful? Presumably they would vote against overruling 
themselves, if there are such options. But it seems that if they don't 
vote, the measure would fail anyway? Or is this more about them choosing 
between multiple options (possibly all of which overrule themselves)?



1. Options which do not have an explicit supermajority requirement have a
1:1 majority requirement. The default option must not have any
supermajority requirements.


"must not" or "does not"?


2. The votes are counted according to the rules in A.6. The default option
is "None of the above," unless specified otherwise.


This "None of the above" seems duplicative of the one above. Do we need 
both?



When the vote counting mechanism of the Standard Resolution Procedure is
to be used, the text which refers to it must specify who has a casting
vote, the quorum, the default option, and any supermajority requirement.


Maybe the "The default option must not have any supermajority 
requirements." should be moved here?


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Re: Draft proposal for resolution process changes

[Gard Spreemann]

Hello, and thank you for this effort.

Russ Allbery  writes:

> A.2. Withdrawing ballot options:
>
> […]
>
> 4. The default option cannot be withdrawn.

This is the most minor of near-useless pedantic comments on my part, but
A.2.4 seems redundant: If only the proposer of a ballot option may
withdraw it (A.2.1), and the default option has no proposer (A.1.7),
then we don't really need a separate rule saying that the default cannot
be withdrawn.


 Best,
 Gard


signature.asc
Description: PGP signature

Draft proposal for resolution process changes

[Russ Allbery]

Hello everyone,

Below is an initial proposal for a revision to the GR and Technical
Committee processes, offered to start a project discussion.

This is not a GR proposal.  Please do not second it at this time.  Since
this is a constitutional change that will require a 3:1 majority, it will
require broad consensus within the project.  My intention is to discuss it
informally until it appears to have rough consensus, or at least until we
have a clear idea of what alternatives we want on the ballot and at least
one of those alternatives seems likely to gain a 3:1 majority.

Nothing is yet set in stone, and changes and discussion are welcomed
gratefully.

This proposal attempts to address the following problems seen in GR and TC
votes:

* Ambiguous constitutional language (particularly "proposer") that leaves
  it unclear who can take which actions with a GR.
* Unclear rules for GRs with options proposed by different people.
* Unpredictable timing for starting a vote that's open to process abuse.
* Lack of clear waiting periods around significant process actions that
  may rob someone of the opportunity to respond to an action.
* A default option of "further discussion" that may imply the project
  wants more discussion, rather than only rejecting all ballot options.

It also addresses the following minor constitutional issues:

* The result of a TC Chair election with multiple options with no defeats
  in the Schwartz set (which is possible given the small number of voters)
  was undefined.
* Untangling the implications of accepted and unaccepted amendments in A.1
  was unnecessarily difficult.
* Members of the public with no relation to the project could in theory
  object to minor changes to a GR.

This proposal was already sufficiently complex that it does not attempt to
address the secret ballot.  I believe that should be a separate discussion
and a separate GR since it's substantially orthogonal to this one.

This proposal intentionally reduces the flexibility of timing of votes in
GRs in favor of predictability, given the project's experiences with
recent GRs and the controversies over how and when votes were called.  I
believe this is the correct trade-off to make, and the correct way to
adjust for the less-flexible schedule is to discuss GRs before proposing
them formally (as with this message).  But I acknowedge that it's a
trade-off.

An initial point for discussion: This proposal still pays a substantial
complexity cost to allow the discussion period to vary from one to four
weeks.  A far simpler (and even more predictable) alternative would be to
say that the discussion period for all GRs is two weeks, and all ballot
changes must be made within thirteen days.  Do we want to explore that
option instead?  Or do we want to explore finding some way to hold a quick
(24 hour voting period) vote to decide whether to close discussion, and
then relax the maximum discussion length?

Many thanks to Pierre-Elliott Bécue, Sam Hartman, and Wouter Verhelst for
their feedback and review of earlier versions of this proposal.  (That
review does not imply that they agree with this draft proposal in its
entirety.)

Proposed constitutional changes, showing only the constitutional points
that would be modified:


4.2. Procedure

[...]

4. The Project Leader has a casting vote. There is a quorum of 3Q. The
   default option is "None of the above."

[...]


6.1. Powers

[...]

7. [...] There is no casting vote. If there are multiple options with no
   defeats in the Schwartz set at the end of A.6.8, the winner will be
   chosen from those options by lot, via a mechanism chosen by the Project
   Secretary.

[...]


6.3. Procedure

1. Resolution process.

   The Technical Committee uses the following process to prepare a
   resolution for vote:

   1. Any member of the Technical Committee may propose a resolution.
  This creates an initial two-option ballot, the other option being
  the default option of "Further discussion." The proposer of the
  resolution becomes the proposer of the ballot option.

   2. Any member of the Technical Committee may add additional ballot
  options or modify or withdraw a ballot option they proposed.

   3. If all ballot options are withdrawn, the process is canceled.

   4. Any member of the Technical Committee may call for a vote on the
  ballot as it currently stands. This vote begins immediately, but if
  any other member of the Technical Committee objects to calling for a
  vote before the vote completes, the vote is canceled and has no
  effect.

   5. Two weeks after the original proposal the ballot is closed to any
  changes and voting starts automatically. This vote cannot be
  canceled.

   6. If voting is started prior to two weeks after the original proposal
  via a call for a vote by a member of the Technical Committee, but
  another member of the Technical Committee objects more than two
  weeks after the original proposal