Re: Waiting for the voting vote to finish... :-)

[Gunnar Wolf]

Jonathan Carter dijo [Tue, Nov 23, 2021 at 06:43:27PM +0200]:
> Ah, I also had one, but can wait my turn. I considered starting a thread in
> -project in the meantime, but I'm slightly concerned of information overload
> between a large discussion on -project and a running vote.
> 
> Not to complicate things further, but perhaps some additional co-ordination
> of upcoming votes might help (assuming that's even possible)?

We could also try a new voting style: A multi-dimensional ballot of
strictly-orthogonal choices! That would be a fun set of results to
detangle...

 

Re: GR: Change the resolution process (corrected)

[Gunnar Wolf]

Russ Allbery dijo [Sun, Nov 21, 2021 at 03:41:18PM -0800]:
> >>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.
> 
> > Suggest making this "None of the above" instead of "Further discussion"
> > to avoid two different default options for TC decisions vs project
> > decisions.
> 
> This was discussed briefly earlier, and for whatever it's worth was
> intentional.  My reasoning was that when the TC is asked to make a
> decision, "None of the above" doesn't conclude that process.  In the TC
> case, it does seem to really mean "further discussion" in the sense that
> the TC hasn't resolved the issue in front of them and has to keep
> discussing it.
> 
> That said, I don't feel strongly about this and can change this if folks
> would prefer, particularly if TC members don't think that's the right way
> to go.


  I would prefer the change to extend also to the TC votes. I think
  it's clear that "none of the above" means we would not have an
  outcome to present, but I feel "none of the above" to be
  clearer.

  Besides, the TC does not only vote when mandated to make a decision;
  we could also host a vote on, say, prospective members to appoint to
  the TC. Take as an example bug #880014 — Had I not been appointed as
  a member, maybe there would be nothing left to discuss. Why mandate
  the then-TC to keep discussing my non-nomination ad nauseam?



signature.asc
Description: PGP signature

Re: GR: Change the resolution process (corrected)

[Simon McVittie]

I've lost track of who wrote:
> > > Suggest making this "None of the above" instead of "Further discussion"
> > > to avoid two different default options for TC decisions vs project
> > > decisions.

On Thu, 25 Nov 2021 at 10:28:55 -0600, Gunnar Wolf wrote:
>   I would prefer the change to extend also to the TC votes. I think
>   it's clear that "none of the above" means we would not have an
>   outcome to present, but I feel "none of the above" to be
>   clearer.

Also a TC member but writing only on my own behalf. I agree with Gunnar
that NOTA seems fine as a default for TC decisions (except for choosing
the TC chair, which is special-cased to have no default).

When we're voting for a DPL, the default is already NOTA, which we've
always interpreted to mean the same thing as "re-open nominations"
(RON) in some other organizations' systems for electing officers:
constitutionally, we need a DPL, so NOTA winning the DPL election would
mean we need to find a different candidate who enough people can agree on
(and the way we would achieve that is by reopening nominations and hoping
someone more popular will volunteer). I think the equivalence between NOTA
and RON has always been uncontroversial. The only reason we don't have
this for the TC chair is that the TC chair has a fixed set of candidates
(the TC members) so reopening nominations would have no practical effect.

Similarly, when the TC has been asked for a decision, a win for NOTA
would mean none of our draft resolutions were accepted, so the decision
is unresolved and we would need to (loosely) "re-open nominations"
to get a better draft resolution that enough TC members can agree on.

In practice, it seems like NOTA/FD is unlikely to win a TC vote: the
only way I can think of for that to happen is if someone called the vote
prematurely, before we got close enough to consensus to be able to write
at least one option that a majority would vote above NOTA/FD.

If the TC is voting to *not* do something (for example if we have been
asked to overrule the foobar maintainer, but we have consensus that
the foobar maintainer was correct), then it seems we implement that by
voting on the resolution we have consensus for (in this case it would be
"formally decline to overrule foobar maintainer" > FD), rather than
putting up a resolution "overrule the foobar maintainer" that none of us
agree with and then voting FD > "overrule the foobar maintainer".
We could equally well do that by voting
"formally decline to overrule foobar maintainer" > NOTA.

smcv

Re: GR: Change the resolution process (corrected)

[Russ Allbery]

Simon McVittie  writes:

> Also a TC member but writing only on my own behalf. I agree with Gunnar
> that NOTA seems fine as a default for TC decisions (except for choosing
> the TC chair, which is special-cased to have no default).

Okay, sounds good.  That's multiple people in support and no one saying
they want to keep it the way I had it, so let's make the change.

I have read the current process *yet again*, and have once again changed
my mind about how this works.  It looks like I can propose a formal
amendment to my own GR since I'm the original proposer (under A.1.1) and
then accept it (under A.1.2).

So, I propose and accept the following amendment:

Change "Further discussion" to "None of the above" in 6.3.1.1 and in
6.3.2.

I will shortly post a new revision of my GR with the minor typo changes
previously discussed and that change.  I didn't get to webwml PRs today
but will try to get to that soon.

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


signature.asc
Description: PGP signature

GR: Change the resolution process (2021-11-25 revision)

[Russ Allbery]

Here is an updated version of my proposal, which incorporates the formal
amendment to change the default option for TC resolutions to also be "None
of the above" and fixes two typos.


Rationale
=

We have uncovered several problems with the current constitutional
mechanism for preparing a Technical Committee resolution or General
Resolution for vote:

* The timing of calling for a vote is discretionary and could be used
  strategically to cut off discussion while others were preparing
  additional ballot options.
* The original proposer of a GR has special control over the timing of the
  vote, which could be used strategically to the disadvantage of other
  ballot options.
* The description of the process for adding and managing additional ballot
  options is difficult to understand.
* The current default choice of "further discussion" for a General
  Resolution has implications beyond rejecting the other options that may,
  contrary to its intent, discourage people Developers ranking it above
  options they wish to reject.

The actual or potential implications of these problems caused conflict in
the Technical Committee systemd vote and in GRs 2019-002 and 2021-002,
which made it harder for the project to reach a fair and widely-respected
result.

This constitutional change attempts to address those issues by

* separating the Technical Committee process from the General Resolution
  process since they have different needs;
* requiring (passive) consensus among TC members that a resolution is
  ready to proceed to a vote;
* setting a maximum discussion period for a TC resolution and then
  triggering a vote;
* setting a maximum discussion period for a GR so that the timing of the
  vote is predictable;
* extending the GR discussion period automatically if the ballot changes;
* modifying the GR process to treat all ballot options equally, with a
  clearer process for addition, withdrawal, and amendment;
* changing the default option for a GR to "none of the above"; and
* clarifying the discretion extended to the Project Secretary.

It also corrects a technical flaw that left the outcome of the vote for
Technical Committee Chair undefined in the event of a tie, and clarifies
responsibilities should the Technical Committee put forward a General
Resolution under point 4.2.1.

Effect of the General Resolution


The Debian Developers, by way of General Resolution, amend the Debian
constitution under point 4.1.2 as follows.  This General Resolution
requires a 3:1 majority.

Section 4.2.4
-

Strike the sentence "The minimum discussion period is 2 weeks, but may be
varied by up to 1 week by the Project Leader."  (A modified version of
this provision is added to section A below.)  Add to the end of this
point:

The default option is "None of the above."

Section 4.2.5
-

Replace "amendments" with "ballot options."

Section 5.1.5
-

Replace in its entirety with:

Propose General Resolutions and ballot options for General
Resolutions.  When proposed by the Project Leader, sponsors for the
General Resolution or ballot option are not required; see §4.2.1.

Section 5.2.7
-

Replace "section §A.6" with "section §A.5".

Section 6.1.7
-

Replace "section §A.6" with "section §A.5".

Add to the end of this point:

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

Section 6.3
---

Replace 6.3.1 in its entirety with:

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 "None of the above". The proposer
  of the resolution becomes the proposer of the ballot option.

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

   3. If all ballot options except the default option 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 a vote is canceled under point 6.3.1.4 later than 13 days
  after the initial proposed resolution, the vote specified in