public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ulrich Mueller <ulm@gentoo.org>
To: "Robin H. Johnson" <robbat2@gentoo.org>
Cc: gentoo-project@lists.gentoo.org, vapier@gentoo.org
Subject: Re: [gentoo-project] Update of Gentoo metastructure document aka GLEP 39
Date: Mon, 10 Apr 2023 23:28:27 +0200	[thread overview]
Message-ID: <u8rezig04@gentoo.org> (raw)
In-Reply-To: <robbat2-20230410T183729-580993760Z@orbis-terrarum.net> (Robin H. Johnson's message of "Mon, 10 Apr 2023 18:48:18 +0000")

[-- Attachment #1: Type: text/plain, Size: 5375 bytes --]

>>>>> On Mon, 10 Apr 2023, Robin H Johnson wrote:

> Mostly looks good to me, some discussion/improvements below.

>> Author: Grant Goodyear <g2boojum@gentoo.org>,
>> Ciaran McCreesh <ciaranm@gentoo.org>
> Nit: I think this needs updates about who significant authors of new
> revisions where.

The only text passage that's more than a single sentence is [1].
It originates from a council summary from 2007 [2]. AFAICS kingtaco
chaired that meeting, but vapier (CCing him) committed the summary.

@robbat2: I also see that you participated in that meeting, do you
remember who the author of that text was?

The other changes are small, and originate from meeting logs and mailing
list discussions. I am happy to add anyone who can claim authorship for
them with a straight face. (I for my part won't, since my work was
mostly editorial.)

>> Version: 2
> Nit: Version needs to be incremented.

Yes, Version and Post-History, and already committed [3].

>> +Updates to this document (other than editorial changes) require a vote
>> +of all developers.  The vote passes if the ratio of positive to negative
>> +votes is at least 2:1, and if the number of positive votes is at least
>> +1/4 of the number of eligible voters.
> 1. This should probably describe how an all-developer vote is quorate,
>    because I don't think that's codified anywhere (and if it IS already
>    codified, it should referenced here).

That's what I was trying to do with the clause "number of positive votes
is at least 1/4 of the number of eligible voters."

> 2. I think this would be clearer formatted as a list:
> ===
> The vote passes if all of the following are satisfied;
> - Ratio of positive to negative votes is at least 2:1
> - The number of positive votes is at least 1/4 of the number of eligible
>   voters.
> - A majority (50% + 1) of developers voted.
> ===

Let's first discuss these ratios, then how to format them. I also think
that we would want a quorum only for positive votes, not for total
votes, because with the latter a negative vote could make a motion pass.

(Example: 200 eligible voters, 75 yes votes, 25 no votes => motion does
not pass. With one additional no vote it would pass. This violates the
monotonicity criterion [4].)

>> +   *  It should have at least one lead, and the leads are selected by
>> +      the members of the project.  This selection should occur at least
>> +      once every 12 months, and may occur at any time.  Any member can
>> +      demand a lead election if the last election was more than
>> +      12 months ago.
> Should consequences of not holding an election when demanded be covered
> here?

I don't think that we need to mention such details here. It would be
escalated in the usual way via ComRel, I guess.

>> +   *  Whenever a member of the council loses their position (the reason
>> +      is irrelevant; e.g. they resign or they are booted for slacking),
>> +      then the next person in line from the previous council election
>> +      is offered the position.  If they accept and the current council
>> +      unanimously accepts the new person, they get the position.
>> +      Otherwise, it is offered to the next person in line, and so forth.
>> +      If the council does not accept that person, then a new election is
>> +      held to choose a new member.  The new member gets a 'reduced' term
>> +      so that the yearly elections still elect a full group.

> Two questions for this section:
> 1) Nit: In the case of tied ranked candidates that would be next in line, how
> are they chosen? E.g. in the council-202106 election [A] there was a tie
> between slyfox & whissi, as well as lu_zero as zx2c4.

That's the same problem as for a tied 7th place in a council election,
and we don't have a solution for that either. (In fact, there was a tie
between ssuominen and myself in 2008-12, and we were able to solve it
amicably [5].)

> 2) Nit: Not likely to have an actual effect on the outcome due to the
> over-supply of candidates at this time, but should the selection go past
> the "_reopen_nominations" meta-candidate?

I think it is obvious that it cannot.

>> *  If any meeting has less than 50% attendance by council members, a new
>> election for *all* places must be held within a month. The 'one year'
>> -      is then reset from that point.
>> +      is then reset from that point.  Any such meeting must dissolve
>> +      immediately after the short roll call.
> Can this be clarified to say that council members may informally discuss
> the scheduled agenda, but the official votes cannot be held? I'd think
> there might be cases where a discussion happens anyway, and then the
> voting is moved to a bug.

How about this instead:

-      is then reset from that point.
+      is then reset from that point.  No substantive action can be
+      taken in any such meeting.

Ulrich

> [A] https://projects.gentoo.org/elections/council/2021/council-202106-results.txt

[1] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=7d642173b0b05a0ebb3e142298a229cfcea8ba81
[2] https://projects.gentoo.org/council/meeting-logs/20070208-summary.txt
[3] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=4d633cde224b5879a3e6f6fa7030165b3605cfa0
[4] https://en.wikipedia.org/wiki/Monotonicity_criterion
[5] https://archives.gentoo.org/gentoo-dev/message/3cf357b8b433b37fd7cd85fa6a22df61

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

  reply	other threads:[~2023-04-10 21:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29  3:43 [gentoo-project] Council Meeting 2023-04-09: Call for Agenda Items John Helmert III
2023-03-29  5:14 ` Ulrich Mueller
2023-03-29  5:29 ` Ulrich Mueller
2023-03-29 14:41   ` Rich Freeman
2023-03-29 16:11     ` Ulrich Mueller
2023-04-10 17:37   ` [gentoo-project] Update of Gentoo metastructure document aka GLEP 39 (was: Re: Council Meeting 2023-04-09: Call for Agenda Items) Ulrich Mueller
2023-04-10 18:48     ` Robin H. Johnson
2023-04-10 21:28       ` Ulrich Mueller [this message]
2023-04-11 16:24         ` [gentoo-project] Update of Gentoo metastructure document aka GLEP 39 Ulrich Mueller
2023-04-15  9:33           ` Roy Bamford
2023-04-16  8:24     ` [gentoo-project] " Ulrich Mueller
2023-04-24  9:18       ` [gentoo-project] Gentoo metastructure update (GLEP 39) voting now open Ulrich Mueller
2023-04-25  7:15         ` Ulrich Mueller
2023-04-30 16:30         ` [gentoo-project] Re: [gentoo-dev-announce] Gentoo metastructure update (GLEP 39) voting now open - 7 days left Jorge Manuel B. S. Vicetto
     [not found]           ` <d43987ddf5371b1b883cfe0b712e683baec62379.camel@gentoo.org>
2023-05-03  6:58             ` Ulrich Mueller
2023-05-03 11:59               ` Michael Orlitzky
2023-03-31 17:02 ` [gentoo-project] Re: Council Meeting 2023-04-09: Call for Agenda Items Andreas K. Huettel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=u8rezig04@gentoo.org \
    --to=ulm@gentoo.org \
    --cc=gentoo-project@lists.gentoo.org \
    --cc=robbat2@gentoo.org \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox