Re: [gentoo-project] Update of Gentoo metastructure document aka GLEP 39 (was: Re: Council Meeting 2023-04-09: Call for Agenda Items)

["Robin H. Johnson" <robbat2@gentoo.org>]

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

On Mon, Apr 10, 2023 at 07:37:48PM +0200, Ulrich Mueller wrote:
> My suggestion is that we discuss these changes on this mailing list
> until 2023-04-23; then I would ask the election team to organize a vote.
Mostly looks good to me, some discussion/improvements below.

> --- a/glep-0039.rst
> +++ b/glep-0039.rst
> @@ -1,14 +1,14 @@
>  ---
>  GLEP: 39
> -Title: An "old-school" metastructure proposal with "boot for being a slacker"
> +Title: Gentoo metastructure
>  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.

>  Type: Informational
>  Status: Final
>  Version: 2
Nit: Version needs to be incremented.

> +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).
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.
===

> +   *  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?

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

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?

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

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

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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