[gentoo-project] Council Meeting 2023-04-09: Call for Agenda Items

[gentoo-project] Council Meeting 2023-04-09: Call for Agenda Items

[John Helmert III]

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

Hello,

Please reply with any topics you wish to be discussed during the next
council meeting (2023-04-09).

Current default agenda:
1. Roll call
2. Open bugs with council participation
3. Open floor

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

Re: [gentoo-project] Council Meeting 2023-04-09: Call for Agenda Items

[Ulrich Mueller]

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

>>>>> On Wed, 29 Mar 2023, John Helmert wrote:

> Please reply with any topics you wish to be discussed during the next
> council meeting (2023-04-09).

I'd like the council to approve another retroactive fix of the econf
logic. We had already updated --disable-static, in order to avoid false
positives in "configure --help" output, but (as pointed out by soap)
--with-sysroot is affected as well.

So, the proposal is to check for proper end of string for all option
names beginning with "with", "disable" or "enable", and apply this
change retroactively to existing EAPIs.

Patch for PMS is in [1].

Ulrich

[1] https://archives.gentoo.org/gentoo-pms/message/3223c4f2b35feb2b27236299cf9e5cb8

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

Re: [gentoo-project] Council Meeting 2023-04-09: Call for Agenda Items

[Ulrich Mueller]

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

>>>>> On Wed, 29 Mar 2023, John Helmert wrote:

> Please reply with any topics you wish to be discussed during the next
> council meeting (2023-04-09).

Some time ago ajak and I had proposed a series of changes for GLEP 39 in
[1] and [2]. These will require an all-developers vote, but I think the
council should discuss the changes first and maybe pre-approve them.

In particular, the changes are:

- Update title [3]
- Updating GLEP 39 requires an all-developers vote [4]
- Replace leaving council members by next in line [5]
- Council members must be developers [6]
- A meeting must dissolve if not quorate [7]
- Projects need not have a lead [8]
- Drop hard requirement of yearly lead elections [9]
- Add summary of changes [10]

Most of them were discussed previously in council meetings or
on the mailing lists. See the commit messages for pointers to these
discussions.

Ulrich

[1] https://archives.gentoo.org/gentoo-project/message/c23c228ac508d19c671da4e4d23c4880
[2] https://archives.gentoo.org/gentoo-project/message/60ca5dac5336b30d71abadaa28bc90ad
[3] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=5ddb7140a90543185dbf05731cdedad83e412fc9
[4] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=50a99510a47016ab0ecadd46dca4f604984c6f13
[5] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=16cc239ad8f68e1d8218409b2aa17c148155d0a3
[6] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=7077c51ad626c2ead5ed95497a54cf78e311f14b
[7] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=0a8d6ae35dea6f7f4a32d3fbc2b6404935660be2
[8] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=fc4d512dba8e4502eec244511f1974e119c56fec
[9] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=52bdf9a83a72e137c148fb4c86a9fa8602649fa1
[10] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=0ecd972919c8489070a79746eefa4b3e50b4cbc4

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

Re: [gentoo-project] Council Meeting 2023-04-09: Call for Agenda Items

[Rich Freeman]

On Wed, Mar 29, 2023 at 1:29 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> - Updating GLEP 39 requires an all-developers vote [4]

Minor suggestion: the text does not say whether this is a simple
majority or something else.  It is probably worth a little thought,
and making it explicit.

I realize this isn't the formal approval of the text, but it might
actually be a nice thing for Council to discuss.

To toss something out, I'd probably suggest at least a 60% majority of
those voting, simply because this is a fairly foundational document
and matters with only a slim majority probably should lead to more
deliberation.

> - Drop hard requirement of yearly lead elections [9]

I like the change to it being a recommendation, but I will note that
this is actually a pretty decent way to assess project activity.  If a
project doesn't really have these kinds of discussions then it doesn't
seem very project-like.  Of course this isn't the only way to measure
activity, but it is one of the things that are public-facing since
this info is supposed to be on the wiki.

-- 
Rich

Re: [gentoo-project] Council Meeting 2023-04-09: Call for Agenda Items

[Ulrich Mueller]

>>>>> On Wed, 29 Mar 2023, Rich Freeman wrote:

> On Wed, Mar 29, 2023 at 1:29 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>> 
>> - Updating GLEP 39 requires an all-developers vote [4]

> Minor suggestion: the text does not say whether this is a simple
> majority or something else.  It is probably worth a little thought,
> and making it explicit.

The metastructure reform (which was published as GLEP 39 later) was
originally accepted in a Condorcet vote [1], which makes it somewhat
difficult to compare it with a simple yes/no question. Voter turnout
at the time was 100 votes out of 381 eligible voters (26.24% of
participation) [2].

The master ballow is also still available [3]. So, I did a simple
analysis, taking only the proposals "Oldschool-small-with-slacker-boot"
(which was accepted), "Keep-current", and "Reopen-nominations" into
account. (The idea is that preferring the accepted proposal to
"Keep-current" is comparable with a "yes" vote.)

- Comparing "Oldschool-small-with-slacker-boot" with "Keep-current":
  67 voters ranked it above, 24 below, 9 with equal rank.

- Comparing "Oldschool-small-with-slacker-boot" with "Reopen-nominations":
  74 voters ranked it above, 17 below, 9 with equal rank.

- Comparing "Oldschool-small-with-slacker-boot" with both,
  63 voters ranked it above both, 28 below at least one of them,
  9 with equal rank.

> I realize this isn't the formal approval of the text, but it might
> actually be a nice thing for Council to discuss.

> To toss something out, I'd probably suggest at least a 60% majority of
> those voting, simply because this is a fairly foundational document
> and matters with only a slim majority probably should lead to more
> deliberation.

We should be careful there. For example, if I take the numbers from
GLEP 77 [4]:

- ratio of positive to negative votes of at least 2:1,
- positive votes no less than 1/4 the number of active developers,

then the original metastructure reform wouldn't have been accepted. With
a ratio of 67:24 of positive to negative votes, it would have made the
first criterion, but with only 67 positive votes out of 381 eligible
voters, it would have failed the second one.

Also, I am not sure if we could impose anything else than a simple
majority for the upcoming vote. Even if we require a 60%, 2/3, or 3/4
majority or a certain quorum in the document, I believe it would only
be applicable to future changes.

Ulrich

[1] https://archives.gentoo.org/gentoo-dev/message/f5ab9ccca62a5d5e0b7b7ab0156f19b3
[2] https://archives.gentoo.org/gentoo-dev/message/dd313930e951d05c574c58a3c20a6276
[3] https://marc.info/?l=gentoo-dev&m=111876215822161
[4] https://www.gentoo.org/glep/glep-0077.html

[gentoo-project] Re: Council Meeting 2023-04-09: Call for Agenda Items

[Andreas K. Huettel]

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

After discussing this with the immediately involved parties (i.e., 
council, comrel, and proctors), I'd like to bring up the following 
motion for a council vote:

"Dissolve the proctors project, with all their responsibilities 
falling back to comrel."

I was the one who mostly pushed ahead the plans for the proctors. 
However, at least as far as I can see there is currently not much
happening and also not much need for the team. So let's simplify
Gentoo's structure again.

Cheers,
Andreas

Am Mittwoch, 29. März 2023, 05:43:48 CEST schrieb John Helmert III:
> Hello,
> 
> Please reply with any topics you wish to be discussed during the next
> council meeting (2023-04-09).
> 
> Current default agenda:
> 1. Roll call
> 2. Open bugs with council participation
> 3. Open floor
> 


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1.1: Type: text/plain, Size: 2836 bytes --]

>>>>> On Wed, 29 Mar 2023, Ulrich Mueller wrote:

> Some time ago ajak and I had proposed a series of changes for GLEP 39 in
> [1] and [2]. These will require an all-developers vote, but I think the
> council should discuss the changes first and maybe pre-approve them.

> In particular, the changes are:

> - Update title [3]
> - Updating GLEP 39 requires an all-developers vote [4]
> - Replace leaving council members by next in line [5]
> - Council members must be developers [6]
> - A meeting must dissolve if not quorate [7]
> - Projects need not have a lead [8]
> - Drop hard requirement of yearly lead elections [9]
> - Add summary of changes [10]

> Most of them were discussed previously in council meetings or
> on the mailing lists. See the commit messages for pointers to these
> discussions.

The update of GLEP 39 was discussed in yesterday's council meeting, and
there was consensus that we should proceed with these changes.

The only point that was discussed was the requirement of a quorum for
future changes, which wasn't specified in the previous version. The
attached version proposes two requirements (which are basically the same
as the ones in GLEP 77):
- ratio of positive to negative at least 2:1, and
- number of positive votes at least 1/4 of the number of developers.

I also took as consensus from yesterday's discussion that these
requirements don't apply retroactively, i.e. the upcoming vote will only
need a simple majority.

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.

Attached are the full text of the proposed new version and a diff
relative to the active version. Individual commits can be seen at:
https://gitweb.gentoo.org/data/glep.git/log/?h=glep39

Ulrich

> [1] https://archives.gentoo.org/gentoo-project/message/c23c228ac508d19c671da4e4d23c4880
> [2] https://archives.gentoo.org/gentoo-project/message/60ca5dac5336b30d71abadaa28bc90ad
> [3] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=5ddb7140a90543185dbf05731cdedad83e412fc9
> [4] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=50a99510a47016ab0ecadd46dca4f604984c6f13
> [5] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=16cc239ad8f68e1d8218409b2aa17c148155d0a3
> [6] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=7077c51ad626c2ead5ed95497a54cf78e311f14b
> [7] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=0a8d6ae35dea6f7f4a32d3fbc2b6404935660be2
> [8] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=fc4d512dba8e4502eec244511f1974e119c56fec
> [9] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=52bdf9a83a72e137c148fb4c86a9fa8602649fa1
> [10] https://gitweb.gentoo.org/data/glep.git/commit/?h=glep39&id=0ecd972919c8489070a79746eefa4b3e50b4cbc4


[-- Attachment #1.2: glep-0039.rst --]
[-- Type: text/plain, Size: 12503 bytes --]

---
GLEP: 39
Title: Gentoo metastructure
Author: Grant Goodyear <g2boojum@gentoo.org>,
        Ciaran McCreesh <ciaranm@gentoo.org>
Type: Informational
Status: Final
Version: 2
Created: 2005-09-01
Last-Modified: 2023-04-10
Post-History: 2005-09-01, 2006-02-09, 2007-10-12, 2008-01-19, 2022-11-25
Content-Type: text/x-rst
Replaces: 4
---

Status
======

Implemented.  The metastructure proposal was accepted by a vote of all
Gentoo developers on 2005-06-14 [#Metastructure_vote]_.
GLEP amended on 2006-02-09 to add the final bullet point to list B in
`Specification`_.

Updated by an all-developers vote on 2023-XX-XX:

* Replace leaving council members by next in line [#Council2007]_.
* Updating this document requires an all-developers vote [#Council2009]_.
* Council members must be developers [#Council2013]_.
* A council meeting must dissolve if not quorate.
* Drop hard requirement of yearly project lead elections.

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.

Abstract
========

GLEP 4 is replaced with a new "metastructure" that retains established
projects (and makes new projects easier to create), but adds a new "Gentoo
Council" to handle global (cross-project) issues.

Motivation
==========

The Fosdem and subsequent reform proposals shepherded by Koon are thorough,
extremely detailed, and somewhat complicated.  They have a lot of good ideas.
For many who have been with Gentoo a long time, though, there's just something
about them that they don't really like.  More than a few Gentoo devs are
almost entirely uninterested in metastructure as long as it doesn't get in
their way, and because the current proposals impose at least some order on our
unruly devs these proposals are guaranteed to "get in the way" to some degree.
For example, a frequent comment that has been heard is that many Gentoo devs
don't know who his/her manager (or project lead) is, which is a clear
indication that our current system is broken.  The existing proposals solve
the problem by requiring that each dev belong to a project.  Perhaps the part
that is broken, though, is the belief that every dev should have a manager.
The history of Gentoo is such that traditionally big advances have often been
implemented by a single or a small number of dedicated devs (thus our
long-standing tradition that devs have access to the entire tree), and surely
we do not want to make things harder (or less fun) for such people.  So here's
a minimal proposal for those who remembers the "good ol' days" and thinks
things aren't really so different now.

Synopsis of the current system
------------------------------

*  There are 13-15 top-level projects (TLPs).  Top-level projects are
   comprised of sub-projects, and the goal was that every Gentoo
   project would be a sub-project of one of the TLPs.  Supposedly each
   dev therefore belongs to one or more TLPs.
*  Each TLP has at least a "strategic" manager, and potentially also an
   "operational" manager.  Only the strategic managers vote on global
   Gentoo issues.
*  The managers of each TLP were appointed by drobbins, the other
   TLP managers, or elected by their project members.  These managers
   have no set term.
*  Within each TLP the managers are responsible for making decisions
   about the project, defining clear goals, roadmaps, and timelines
   for the project, and solving problems that arise within the TLP
   (see GLEP 4 for the specific list).
*  The strategic TLP managers are also responsible for deciding issues that
   affect Gentoo across project lines.  The primary mechanism for
   handling global-scope issues is the managers' meetings.
*  Disciplinary action taken against erring devs is handled by the
   "devrel" TLP, unless the dev is a strategic TLP manager.  In that
   case disciplinary action must be enacted by the other strategic TLP
   managers.

Problems with the existing system
---------------------------------

1. The assumption that TLPs are complete is either incorrect (there
   still is no "server" TLP) or just plain weird (but the lack of a
   server TLP is technically okay because all devs who don't have an
   obvious TLP belong to the "base" TLP by default).
2. There is nothing at all to ensure that project leads actually do
   represent the devs they supposedly lead or satisfy their
   responsibilities.  Indeed, should a TLP manager go AWOL it is not at
   all obvious how the situation should be resolved.
3. Nothing is being decided at global scope right now.  Some TLP strategic
   managers rarely attend the managers' meetings, and the managers as a
   whole certainly are not providing any sort of global vision for
   Gentoo right now.
4. Even if the strategic TLP managers were making global decisions for
   Gentoo, the TLP structure is such that almost all devs fall under
   only one or two TLPs.  Thus voting on global issues is hardly
   proportional, and thus many devs feel disenfranchised.
5. Regardless of whether or not it is justified, devrel is loathed by
   many in its enforcement role.

Additional problems identified by the current metastructure reform proposals
----------------------------------------------------------------------------

6. The current system has no mechanism for identifying either projects
   or devs that have gone inactive.
7. Bugs that cut across projects often remain unresolved.
8. GLEPs often linger in an undetermined state.

Specification
=============

A. A project is a group of developers working towards a goal (or a set
   of goals).

   *  A project exists if it has a maintained Wiki
      project page as described below.  ("Maintained" means
      that the information on the page is factually correct and not
      out-of-date.)  If the Wiki page isn't maintained, it is presumed
      dead.
   *  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.
   *  It may have zero or more sub-projects.  Sub-projects are
      just projects that provide some additional structure, and their
      Wiki pages are defined as sub-projects of the parent project.
   *  Not everything (or everyone) needs a project.
   *  Projects need not be long-term.
   *  Projects may well conflict with other projects.  That's okay.
   *  Any dev may create a new project just by creating a new project
      page on the wiki.gentoo.org (see [#Project_pages]_) and sending
      a Request For Comments (RFC) e-mail to gentoo-dev.  Note that
      this GLEP does not provide for a way for the community at large
      to block a new project, even if the comments are wholly negative.

B. Global issues will be decided by an elected Gentoo council.

   *  There will be a set number of council members.  (For the
      first election that number was set to 7 by acclamation.)
   *  Council members will be chosen by a general election of all
      devs once per year.
   *  Council members (and their proxies) must be Gentoo developers.
   *  The council must hold an open meeting at least once per month.
   *  Council decisions are by majority vote of those who show up (or
      their proxies).
   *  If a council member (or their appointed proxy) fails to show up for
      two consecutive meetings, they are marked as a slacker.
   *  If a council member who has been marked a slacker misses any further
      meeting (or their appointed proxy doesn't show up), they lose their
      position.
   *  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.
   *  Council members who have previously been booted for excessive slacking
      may stand for future elections, including the election for their
      replacement. They should, however, justify their slackerness, and
      should expect to have it pointed out if they don't do so themselves.
   *  The 'slacker' marker is reset when a member is elected.
   *  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.  Any such meeting must dissolve
      immediately after the short roll call.
   *  Disciplinary actions may be appealed to the council.
   *  A proxy must not be an existing council member, and any single person
      may not be a proxy for more than one council member at any given
      meeting.

Rationale
=========

So, does this proposal solve any of the previously-mentioned problems?

1. There is no longer any requirement that the project structure be
   complete.  Some devs work on very specific parts of the tree, while
   some work on practically everything; neither should be shoehorned into
   an ad-hoc project structure.  Moreover, it should be easy to create new
   projects where needed (and remove them when they are not), which this
   proposal should enable.

2. By having the members choose their project leads periodically, the
   project leads are necessarily at least somewhat responsible (and
   hopefully responsive) to the project members.  This proposal has
   removed the list of responsibilities that project leads were supposed
   to satisfy, since hardly anybody has ever looked at the original list
   since it was written.  Instead the practical responsibility of a lead
   is "whatever the members require", and if that isn't satisfied, the
   members can get a new lead (if they can find somebody to take the job!).

3. If the council does a lousy job handling global issues (or has no
   global vision), vote out the bums.

4. Since everybody gets to vote for the council members, at least in
   principle the council members represent all developers, not just a
   particular subset.

5. An appeal process should make disciplinary enforcement both less
   capricious and more palatable.

6. This proposal doesn't help find inactive devs or projects.  It really
   should not be that much of a problem.  We already have a script
   for identifying devs who haven't made a CVS commit within a certain
   period of time.  As for moribund projects, if the project page isn't
   maintained, it's dead, and we should remove it.  That, too, could be
   automated.  A much bigger problem is understaffed herds, but more
   organization is not necessarily a solution.

7. The metabug project is a great idea.  Let's do that!  Adding a useful
   project shouldn't require "metastructure reform", although with the
   current system it does.  With this proposal it wouldn't.

8. This proposal has nothing to say about GLEPs.

References
==========

.. [#Metastructure_vote] Grant Goodyear, "Metastructure vote preliminary
   results", posted to ``gentoo-dev`` mailing list on 2005-06-14,
   Message-ID 20050614035141.GC15256\@dst.grantgoodyear.org
   (https://archives.gentoo.org/gentoo-dev/message/f5ab9ccca62a5d5e0b7b7ab0156f19b3)

.. [#Project_pages] https://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages

.. [#Council2007] 2007-02-08 council meeting
   (https://projects.gentoo.org/council/meeting-logs/20070208-summary.txt)

.. [#Council2009] 2009-07-20 council meeting
   (https://projects.gentoo.org/council/meeting-logs/20090720-summary.txt),
   confirmed on 2011-07-15
   (https://projects.gentoo.org/council/meeting-logs/20110715-summary.txt)

.. [#Council2013] 2013-02-12 council meeting
   (https://projects.gentoo.org/council/meeting-logs/20130212-summary.txt)

Copyright
=========

This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
International License.  To view a copy of this license, visit
https://creativecommons.org/licenses/by-sa/4.0/.

[-- Attachment #1.3: glep-0039.diff --]
[-- Type: text/plain, Size: 5973 bytes --]

--- 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>
 Type: Informational
 Status: Final
 Version: 2
 Created: 2005-09-01
-Last-Modified: 2019-11-07
-Post-History: 2005-09-01, 2006-02-09, 2007-10-12, 2008-01-19
+Last-Modified: 2023-04-10
+Post-History: 2005-09-01, 2006-02-09, 2007-10-12, 2008-01-19, 2022-11-25
 Content-Type: text/x-rst
 Replaces: 4
 ---
@@ -21,6 +21,19 @@ Gentoo developers on 2005-06-14 [#Metastructure_vote]_.
 GLEP amended on 2006-02-09 to add the final bullet point to list B in
 `Specification`_.
 
+Updated by an all-developers vote on 2023-XX-XX:
+
+* Replace leaving council members by next in line [#Council2007]_.
+* Updating this document requires an all-developers vote [#Council2009]_.
+* Council members must be developers [#Council2013]_.
+* A council meeting must dissolve if not quorate.
+* Drop hard requirement of yearly project lead elections.
+
+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.
+
 Abstract
 ========
 
@@ -116,10 +129,11 @@ A. A project is a group of developers working towards a goal (or a set
       that the information on the page is factually correct and not
       out-of-date.)  If the Wiki page isn't maintained, it is presumed
       dead.
-   *  It may have one or many leads, and the leads are
-      selected by the members of the project.  This selection must
-      occur at least once every 12 months, and may occur at any
-      time.
+   *  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.
    *  It may have zero or more sub-projects.  Sub-projects are
       just projects that provide some additional structure, and their
       Wiki pages are defined as sub-projects of the parent project.
@@ -138,6 +152,7 @@ B. Global issues will be decided by an elected Gentoo council.
       first election that number was set to 7 by acclamation.)
    *  Council members will be chosen by a general election of all
       devs once per year.
+   *  Council members (and their proxies) must be Gentoo developers.
    *  The council must hold an open meeting at least once per month.
    *  Council decisions are by majority vote of those who show up (or
       their proxies).
@@ -145,9 +160,16 @@ B. Global issues will be decided by an elected Gentoo council.
       two consecutive meetings, they are marked as a slacker.
    *  If a council member who has been marked a slacker misses any further
       meeting (or their appointed proxy doesn't show up), they lose their
-      position and a new election is held to replace that person. The newly
-      elected council member gets a 'reduced' term so that the yearly
-      elections still elect a full group.
+      position.
+   *  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.
    *  Council members who have previously been booted for excessive slacking
       may stand for future elections, including the election for their
       replacement. They should, however, justify their slackerness, and
@@ -155,7 +177,8 @@ B. Global issues will be decided by an elected Gentoo council.
    *  The 'slacker' marker is reset when a member is elected.
    *  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.
    *  Disciplinary actions may be appealed to the council.
    *  A proxy must not be an existing council member, and any single person
       may not be a proxy for more than one council member at any given
@@ -216,9 +239,20 @@ References
 
 .. [#Project_pages] https://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages
 
+.. [#Council2007] 2007-02-08 council meeting
+   (https://projects.gentoo.org/council/meeting-logs/20070208-summary.txt)
+
+.. [#Council2009] 2009-07-20 council meeting
+   (https://projects.gentoo.org/council/meeting-logs/20090720-summary.txt),
+   confirmed on 2011-07-15
+   (https://projects.gentoo.org/council/meeting-logs/20110715-summary.txt)
+
+.. [#Council2013] 2013-02-12 council meeting
+   (https://projects.gentoo.org/council/meeting-logs/20130212-summary.txt)
+
 Copyright
 =========
 
-This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
-Unported License.  To view a copy of this license, visit
-https://creativecommons.org/licenses/by-sa/3.0/.
+This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
+International License.  To view a copy of this license, visit
+https://creativecommons.org/licenses/by-sa/4.0/.

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

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]

[-- 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 --]

Re: [gentoo-project] Update of Gentoo metastructure document aka GLEP 39

[Ulrich Mueller]

[-- 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 --]

Re: [gentoo-project] Update of Gentoo metastructure document aka GLEP 39

[Ulrich Mueller]

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

>>>>> On Mon, 10 Apr 2023, Ulrich Mueller wrote:

>>>>> On Mon, 10 Apr 2023, Robin H Johnson wrote:
>> 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].)

I have converted it to a list, and moved it to its own section:

--- a/glep-0039.rst
+++ b/glep-0039.rst
@@ -206,6 +206,18 @@
 
 8. This proposal has nothing to say about GLEPs.
 
+Updates to this document
+========================
+
+Any major updates to this document (that is, those that change its
+content rather than just fixing typos or adding small clarifications)
+require a vote of all developers.  The vote passes if both of the
+following conditions are fulfilled:
+
+* The ratio of positive to negative votes is at least two to one, and
+* the number of positive votes is no less than one quarter of the number
+  of eligible voters.
+
 References
 ==========
 

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

Re: [gentoo-project] Update of Gentoo metastructure document aka GLEP 39

[Roy Bamford]

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

On 2023.04.11 17:24, Ulrich Mueller wrote:
[snip]

> +* The ratio of positive to negative votes is at least two to one, and
> +* the number of positive votes is no less than one quarter of the
> number
> +  of eligible voters.
[snip]


Team,

I don't see "eligible voters" defined anywhere, except in terms of the 
variable "all gentoo developers" For the practical purposes of running
a vote, that variable needs to be sampled at some point before the vote
opens.

The elections project has used all gentoo developers at 24 hours before
voting opens as the sampling time to define the electorate.

For the avoidance of doubt, additions to roll call after the sample point 
will not be eligible to vole. Removals from roll call will be.

Does this more formal definition of "eligible voters" need to be included
in GLEP39 or is its always been that way good enough?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

[-- Attachment #2: Type: application/pgp-signature, Size: 488 bytes --]

[gentoo-project] Re: Update of Gentoo metastructure document aka GLEP 39

[Ulrich Mueller]

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

>>>>> On Mon, 10 Apr 2023, 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.

> Attached are the full text of the proposed new version and a diff
> relative to the active version. Individual commits can be seen at:
> https://gitweb.gentoo.org/data/glep.git/log/?h=glep39

Updated version below, which includes feedback from robbat2 and
neddyseagoon.

I am inlining the full text and the squashed diff this time, because
attachments won't show in the mailing list archives.

Ulrich

----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----
---
GLEP: 39
Title: Gentoo metastructure
Author: Grant Goodyear <g2boojum@gentoo.org>,
        Ciaran McCreesh <ciaranm@gentoo.org>
Type: Informational
Status: Final
Version: 3
Created: 2005-09-01
Last-Modified: 2023-04-16
Post-History: 2005-09-01, 2006-02-09, 2007-10-12, 2008-01-19, 2022-11-25,
              2023-04-10, 2023-04-16
Content-Type: text/x-rst
Replaces: 4
---

Status
======

Implemented.  The metastructure proposal was accepted by a vote of all
Gentoo developers on 2005-06-14 [#Metastructure_vote]_.
GLEP amended on 2006-02-09 to add the final bullet point to list B in
`Specification`_.

Updated by an all-developers vote on 2023-XX-XX:

* Replace leaving council members by next in line [#Council2007]_.
* Updating this document requires an all-developers vote [#Council2009]_.
* Council members must be developers [#Council2013]_.
* An inquorate council meeting cannot take any substantive action.
* Drop hard requirement of yearly project lead elections.

Abstract
========

GLEP 4 is replaced with a new "metastructure" that retains established
projects (and makes new projects easier to create), but adds a new "Gentoo
Council" to handle global (cross-project) issues.

Motivation
==========

The Fosdem and subsequent reform proposals shepherded by Koon are thorough,
extremely detailed, and somewhat complicated.  They have a lot of good ideas.
For many who have been with Gentoo a long time, though, there's just something
about them that they don't really like.  More than a few Gentoo devs are
almost entirely uninterested in metastructure as long as it doesn't get in
their way, and because the current proposals impose at least some order on our
unruly devs these proposals are guaranteed to "get in the way" to some degree.
For example, a frequent comment that has been heard is that many Gentoo devs
don't know who his/her manager (or project lead) is, which is a clear
indication that our current system is broken.  The existing proposals solve
the problem by requiring that each dev belong to a project.  Perhaps the part
that is broken, though, is the belief that every dev should have a manager.
The history of Gentoo is such that traditionally big advances have often been
implemented by a single or a small number of dedicated devs (thus our
long-standing tradition that devs have access to the entire tree), and surely
we do not want to make things harder (or less fun) for such people.  So here's
a minimal proposal for those who remembers the "good ol' days" and thinks
things aren't really so different now.

Synopsis of the current system
------------------------------

*  There are 13-15 top-level projects (TLPs).  Top-level projects are
   comprised of sub-projects, and the goal was that every Gentoo
   project would be a sub-project of one of the TLPs.  Supposedly each
   dev therefore belongs to one or more TLPs.
*  Each TLP has at least a "strategic" manager, and potentially also an
   "operational" manager.  Only the strategic managers vote on global
   Gentoo issues.
*  The managers of each TLP were appointed by drobbins, the other
   TLP managers, or elected by their project members.  These managers
   have no set term.
*  Within each TLP the managers are responsible for making decisions
   about the project, defining clear goals, roadmaps, and timelines
   for the project, and solving problems that arise within the TLP
   (see GLEP 4 for the specific list).
*  The strategic TLP managers are also responsible for deciding issues that
   affect Gentoo across project lines.  The primary mechanism for
   handling global-scope issues is the managers' meetings.
*  Disciplinary action taken against erring devs is handled by the
   "devrel" TLP, unless the dev is a strategic TLP manager.  In that
   case disciplinary action must be enacted by the other strategic TLP
   managers.

Problems with the existing system
---------------------------------

1. The assumption that TLPs are complete is either incorrect (there
   still is no "server" TLP) or just plain weird (but the lack of a
   server TLP is technically okay because all devs who don't have an
   obvious TLP belong to the "base" TLP by default).
2. There is nothing at all to ensure that project leads actually do
   represent the devs they supposedly lead or satisfy their
   responsibilities.  Indeed, should a TLP manager go AWOL it is not at
   all obvious how the situation should be resolved.
3. Nothing is being decided at global scope right now.  Some TLP strategic
   managers rarely attend the managers' meetings, and the managers as a
   whole certainly are not providing any sort of global vision for
   Gentoo right now.
4. Even if the strategic TLP managers were making global decisions for
   Gentoo, the TLP structure is such that almost all devs fall under
   only one or two TLPs.  Thus voting on global issues is hardly
   proportional, and thus many devs feel disenfranchised.
5. Regardless of whether or not it is justified, devrel is loathed by
   many in its enforcement role.

Additional problems identified by the current metastructure reform proposals
----------------------------------------------------------------------------

6. The current system has no mechanism for identifying either projects
   or devs that have gone inactive.
7. Bugs that cut across projects often remain unresolved.
8. GLEPs often linger in an undetermined state.

Specification
=============

A. A project is a group of developers working towards a goal (or a set
   of goals).

   *  A project exists if it has a maintained Wiki
      project page as described below.  ("Maintained" means
      that the information on the page is factually correct and not
      out-of-date.)  If the Wiki page isn't maintained, it is presumed
      dead.
   *  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.
   *  It may have zero or more sub-projects.  Sub-projects are
      just projects that provide some additional structure, and their
      Wiki pages are defined as sub-projects of the parent project.
   *  Not everything (or everyone) needs a project.
   *  Projects need not be long-term.
   *  Projects may well conflict with other projects.  That's okay.
   *  Any dev may create a new project just by creating a new project
      page on the wiki.gentoo.org (see [#Project_pages]_) and sending
      a Request For Comments (RFC) e-mail to gentoo-dev.  Note that
      this GLEP does not provide for a way for the community at large
      to block a new project, even if the comments are wholly negative.

B. Global issues will be decided by an elected Gentoo council.

   *  There will be a set number of council members.  (For the
      first election that number was set to 7 by acclamation.)
   *  Council members will be chosen by a general election of all
      devs once per year.
   *  Council members (and their proxies) must be Gentoo developers.
   *  The council must hold an open meeting at least once per month.
   *  Council decisions are by majority vote of those who show up (or
      their proxies).
   *  If a council member (or their appointed proxy) fails to show up for
      two consecutive meetings, they are marked as a slacker.
   *  If a council member who has been marked a slacker misses any further
      meeting (or their appointed proxy doesn't show up), they lose their
      position.
   *  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.
   *  Council members who have previously been booted for excessive slacking
      may stand for future elections, including the election for their
      replacement. They should, however, justify their slackerness, and
      should expect to have it pointed out if they don't do so themselves.
   *  The 'slacker' marker is reset when a member is elected.
   *  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.  No substantive action can be taken
      in any such meeting.
   *  Disciplinary actions may be appealed to the council.
   *  A proxy must not be an existing council member, and any single person
      may not be a proxy for more than one council member at any given
      meeting.

Rationale
=========

So, does this proposal solve any of the previously-mentioned problems?

1. There is no longer any requirement that the project structure be
   complete.  Some devs work on very specific parts of the tree, while
   some work on practically everything; neither should be shoehorned into
   an ad-hoc project structure.  Moreover, it should be easy to create new
   projects where needed (and remove them when they are not), which this
   proposal should enable.

2. By having the members choose their project leads periodically, the
   project leads are necessarily at least somewhat responsible (and
   hopefully responsive) to the project members.  This proposal has
   removed the list of responsibilities that project leads were supposed
   to satisfy, since hardly anybody has ever looked at the original list
   since it was written.  Instead the practical responsibility of a lead
   is "whatever the members require", and if that isn't satisfied, the
   members can get a new lead (if they can find somebody to take the job!).

3. If the council does a lousy job handling global issues (or has no
   global vision), vote out the bums.

4. Since everybody gets to vote for the council members, at least in
   principle the council members represent all developers, not just a
   particular subset.

5. An appeal process should make disciplinary enforcement both less
   capricious and more palatable.

6. This proposal doesn't help find inactive devs or projects.  It really
   should not be that much of a problem.  We already have a script
   for identifying devs who haven't made a CVS commit within a certain
   period of time.  As for moribund projects, if the project page isn't
   maintained, it's dead, and we should remove it.  That, too, could be
   automated.  A much bigger problem is understaffed herds, but more
   organization is not necessarily a solution.

7. The metabug project is a great idea.  Let's do that!  Adding a useful
   project shouldn't require "metastructure reform", although with the
   current system it does.  With this proposal it wouldn't.

8. This proposal has nothing to say about GLEPs.

Updates to this document
========================

Any major updates to this document (that is, those that change its
content rather than just fixing typos or adding small clarifications)
require a vote of all developers.  Eligible voters are all developers
at the time when the proposed update is published.  The vote passes if
both of the following conditions are fulfilled:

* The ratio of positive to negative votes is at least two to one, and
* the number of positive votes is no less than one quarter of the number
  of eligible voters.

References
==========

.. [#Metastructure_vote] Grant Goodyear, "Metastructure vote preliminary
   results", posted to ``gentoo-dev`` mailing list on 2005-06-14,
   Message-ID 20050614035141.GC15256\@dst.grantgoodyear.org
   (https://archives.gentoo.org/gentoo-dev/message/f5ab9ccca62a5d5e0b7b7ab0156f19b3)

.. [#Project_pages] https://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages

.. [#Council2007] 2007-02-08 council meeting
   (https://projects.gentoo.org/council/meeting-logs/20070208-summary.txt)

.. [#Council2009] 2009-07-20 council meeting
   (https://projects.gentoo.org/council/meeting-logs/20090720-summary.txt),
   confirmed on 2011-07-15
   (https://projects.gentoo.org/council/meeting-logs/20110715-summary.txt)

.. [#Council2013] 2013-02-12 council meeting
   (https://projects.gentoo.org/council/meeting-logs/20130212-summary.txt)

Copyright
=========

This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
International License.  To view a copy of this license, visit
https://creativecommons.org/licenses/by-sa/4.0/.
----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----
--- a/glep-0039.rst
+++ b/glep-0039.rst
@@ -1,14 +1,15 @@
 ---
 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>
 Type: Informational
 Status: Final
-Version: 2
+Version: 3
 Created: 2005-09-01
-Last-Modified: 2019-11-07
-Post-History: 2005-09-01, 2006-02-09, 2007-10-12, 2008-01-19
+Last-Modified: 2023-04-16
+Post-History: 2005-09-01, 2006-02-09, 2007-10-12, 2008-01-19, 2022-11-25,
+              2023-04-10, 2023-04-16
 Content-Type: text/x-rst
 Replaces: 4
 ---
@@ -21,6 +22,14 @@ Gentoo developers on 2005-06-14 [#Metastructure_vote]_.
 GLEP amended on 2006-02-09 to add the final bullet point to list B in
 `Specification`_.
 
+Updated by an all-developers vote on 2023-XX-XX:
+
+* Replace leaving council members by next in line [#Council2007]_.
+* Updating this document requires an all-developers vote [#Council2009]_.
+* Council members must be developers [#Council2013]_.
+* An inquorate council meeting cannot take any substantive action.
+* Drop hard requirement of yearly project lead elections.
+
 Abstract
 ========
 
@@ -116,10 +125,11 @@ A. A project is a group of developers working towards a goal (or a set
       that the information on the page is factually correct and not
       out-of-date.)  If the Wiki page isn't maintained, it is presumed
       dead.
-   *  It may have one or many leads, and the leads are
-      selected by the members of the project.  This selection must
-      occur at least once every 12 months, and may occur at any
-      time.
+   *  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.
    *  It may have zero or more sub-projects.  Sub-projects are
       just projects that provide some additional structure, and their
       Wiki pages are defined as sub-projects of the parent project.
@@ -138,6 +148,7 @@ B. Global issues will be decided by an elected Gentoo council.
       first election that number was set to 7 by acclamation.)
    *  Council members will be chosen by a general election of all
       devs once per year.
+   *  Council members (and their proxies) must be Gentoo developers.
    *  The council must hold an open meeting at least once per month.
    *  Council decisions are by majority vote of those who show up (or
       their proxies).
@@ -145,9 +156,16 @@ B. Global issues will be decided by an elected Gentoo council.
       two consecutive meetings, they are marked as a slacker.
    *  If a council member who has been marked a slacker misses any further
       meeting (or their appointed proxy doesn't show up), they lose their
-      position and a new election is held to replace that person. The newly
-      elected council member gets a 'reduced' term so that the yearly
-      elections still elect a full group.
+      position.
+   *  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.
    *  Council members who have previously been booted for excessive slacking
       may stand for future elections, including the election for their
       replacement. They should, however, justify their slackerness, and
@@ -155,7 +173,8 @@ B. Global issues will be decided by an elected Gentoo council.
    *  The 'slacker' marker is reset when a member is elected.
    *  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.  No substantive action can be taken
+      in any such meeting.
    *  Disciplinary actions may be appealed to the council.
    *  A proxy must not be an existing council member, and any single person
       may not be a proxy for more than one council member at any given
@@ -206,6 +225,19 @@ So, does this proposal solve any of the previously-mentioned problems?
 
 8. This proposal has nothing to say about GLEPs.
 
+Updates to this document
+========================
+
+Any major updates to this document (that is, those that change its
+content rather than just fixing typos or adding small clarifications)
+require a vote of all developers.  Eligible voters are all developers
+at the time when the proposed update is published.  The vote passes if
+both of the following conditions are fulfilled:
+
+* The ratio of positive to negative votes is at least two to one, and
+* the number of positive votes is no less than one quarter of the number
+  of eligible voters.
+
 References
 ==========
 
@@ -216,9 +248,20 @@ References
 
 .. [#Project_pages] https://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages
 
+.. [#Council2007] 2007-02-08 council meeting
+   (https://projects.gentoo.org/council/meeting-logs/20070208-summary.txt)
+
+.. [#Council2009] 2009-07-20 council meeting
+   (https://projects.gentoo.org/council/meeting-logs/20090720-summary.txt),
+   confirmed on 2011-07-15
+   (https://projects.gentoo.org/council/meeting-logs/20110715-summary.txt)
+
+.. [#Council2013] 2013-02-12 council meeting
+   (https://projects.gentoo.org/council/meeting-logs/20130212-summary.txt)
+
 Copyright
 =========
 
-This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
-Unported License.  To view a copy of this license, visit
-https://creativecommons.org/licenses/by-sa/3.0/.
+This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
+International License.  To view a copy of this license, visit
+https://creativecommons.org/licenses/by-sa/4.0/.
----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----

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

[gentoo-project] Gentoo metastructure update (GLEP 39) voting now open

[Ulrich Mueller]

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

Voting for the update of the Gentoo metastructure document (GLEP 39)
is now open. The election is named "metastructure-2023".

Login to dev.gentoo.org and use "votify --help" to get instructions
on how to vote, verify, and submit your ballot.

Voting closes at 2023-05-08 00:00:00 UTC (= end of day 2023-05-07).

Since mailing list archives aren't currently working (and I don't want
to point to a third-party archive), I include the full text of the
proposed new version and a diff relative to the active version again.

Regards,
Ulrich

----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----
---
GLEP: 39
Title: Gentoo metastructure
Author: Grant Goodyear <g2boojum@gentoo.org>,
        Ciaran McCreesh <ciaranm@gentoo.org>
Type: Informational
Status: Final
Version: 3
Created: 2005-09-01
Last-Modified: 2023-04-16
Post-History: 2005-09-01, 2006-02-09, 2007-10-12, 2008-01-19, 2022-11-25,
              2023-04-10, 2023-04-16
Content-Type: text/x-rst
Replaces: 4
---

Status
======

Implemented.  The metastructure proposal was accepted by a vote of all
Gentoo developers on 2005-06-14 [#Metastructure_vote]_.
GLEP amended on 2006-02-09 to add the final bullet point to list B in
`Specification`_.

Updated by an all-developers vote on 2023-XX-XX:

* Replace leaving council members by next in line [#Council2007]_.
* Updating this document requires an all-developers vote [#Council2009]_.
* Council members must be developers [#Council2013]_.
* An inquorate council meeting cannot take any substantive action.
* Drop hard requirement of yearly project lead elections.

Abstract
========

GLEP 4 is replaced with a new "metastructure" that retains established
projects (and makes new projects easier to create), but adds a new "Gentoo
Council" to handle global (cross-project) issues.

Motivation
==========

The Fosdem and subsequent reform proposals shepherded by Koon are thorough,
extremely detailed, and somewhat complicated.  They have a lot of good ideas.
For many who have been with Gentoo a long time, though, there's just something
about them that they don't really like.  More than a few Gentoo devs are
almost entirely uninterested in metastructure as long as it doesn't get in
their way, and because the current proposals impose at least some order on our
unruly devs these proposals are guaranteed to "get in the way" to some degree.
For example, a frequent comment that has been heard is that many Gentoo devs
don't know who his/her manager (or project lead) is, which is a clear
indication that our current system is broken.  The existing proposals solve
the problem by requiring that each dev belong to a project.  Perhaps the part
that is broken, though, is the belief that every dev should have a manager.
The history of Gentoo is such that traditionally big advances have often been
implemented by a single or a small number of dedicated devs (thus our
long-standing tradition that devs have access to the entire tree), and surely
we do not want to make things harder (or less fun) for such people.  So here's
a minimal proposal for those who remembers the "good ol' days" and thinks
things aren't really so different now.

Synopsis of the current system
------------------------------

*  There are 13-15 top-level projects (TLPs).  Top-level projects are
   comprised of sub-projects, and the goal was that every Gentoo
   project would be a sub-project of one of the TLPs.  Supposedly each
   dev therefore belongs to one or more TLPs.
*  Each TLP has at least a "strategic" manager, and potentially also an
   "operational" manager.  Only the strategic managers vote on global
   Gentoo issues.
*  The managers of each TLP were appointed by drobbins, the other
   TLP managers, or elected by their project members.  These managers
   have no set term.
*  Within each TLP the managers are responsible for making decisions
   about the project, defining clear goals, roadmaps, and timelines
   for the project, and solving problems that arise within the TLP
   (see GLEP 4 for the specific list).
*  The strategic TLP managers are also responsible for deciding issues that
   affect Gentoo across project lines.  The primary mechanism for
   handling global-scope issues is the managers' meetings.
*  Disciplinary action taken against erring devs is handled by the
   "devrel" TLP, unless the dev is a strategic TLP manager.  In that
   case disciplinary action must be enacted by the other strategic TLP
   managers.

Problems with the existing system
---------------------------------

1. The assumption that TLPs are complete is either incorrect (there
   still is no "server" TLP) or just plain weird (but the lack of a
   server TLP is technically okay because all devs who don't have an
   obvious TLP belong to the "base" TLP by default).
2. There is nothing at all to ensure that project leads actually do
   represent the devs they supposedly lead or satisfy their
   responsibilities.  Indeed, should a TLP manager go AWOL it is not at
   all obvious how the situation should be resolved.
3. Nothing is being decided at global scope right now.  Some TLP strategic
   managers rarely attend the managers' meetings, and the managers as a
   whole certainly are not providing any sort of global vision for
   Gentoo right now.
4. Even if the strategic TLP managers were making global decisions for
   Gentoo, the TLP structure is such that almost all devs fall under
   only one or two TLPs.  Thus voting on global issues is hardly
   proportional, and thus many devs feel disenfranchised.
5. Regardless of whether or not it is justified, devrel is loathed by
   many in its enforcement role.

Additional problems identified by the current metastructure reform proposals
----------------------------------------------------------------------------

6. The current system has no mechanism for identifying either projects
   or devs that have gone inactive.
7. Bugs that cut across projects often remain unresolved.
8. GLEPs often linger in an undetermined state.

Specification
=============

A. A project is a group of developers working towards a goal (or a set
   of goals).

   *  A project exists if it has a maintained Wiki
      project page as described below.  ("Maintained" means
      that the information on the page is factually correct and not
      out-of-date.)  If the Wiki page isn't maintained, it is presumed
      dead.
   *  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.
   *  It may have zero or more sub-projects.  Sub-projects are
      just projects that provide some additional structure, and their
      Wiki pages are defined as sub-projects of the parent project.
   *  Not everything (or everyone) needs a project.
   *  Projects need not be long-term.
   *  Projects may well conflict with other projects.  That's okay.
   *  Any dev may create a new project just by creating a new project
      page on the wiki.gentoo.org (see [#Project_pages]_) and sending
      a Request For Comments (RFC) e-mail to gentoo-dev.  Note that
      this GLEP does not provide for a way for the community at large
      to block a new project, even if the comments are wholly negative.

B. Global issues will be decided by an elected Gentoo council.

   *  There will be a set number of council members.  (For the
      first election that number was set to 7 by acclamation.)
   *  Council members will be chosen by a general election of all
      devs once per year.
   *  Council members (and their proxies) must be Gentoo developers.
   *  The council must hold an open meeting at least once per month.
   *  Council decisions are by majority vote of those who show up (or
      their proxies).
   *  If a council member (or their appointed proxy) fails to show up for
      two consecutive meetings, they are marked as a slacker.
   *  If a council member who has been marked a slacker misses any further
      meeting (or their appointed proxy doesn't show up), they lose their
      position.
   *  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.
   *  Council members who have previously been booted for excessive slacking
      may stand for future elections, including the election for their
      replacement. They should, however, justify their slackerness, and
      should expect to have it pointed out if they don't do so themselves.
   *  The 'slacker' marker is reset when a member is elected.
   *  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.  No substantive action can be taken
      in any such meeting.
   *  Disciplinary actions may be appealed to the council.
   *  A proxy must not be an existing council member, and any single person
      may not be a proxy for more than one council member at any given
      meeting.

Rationale
=========

So, does this proposal solve any of the previously-mentioned problems?

1. There is no longer any requirement that the project structure be
   complete.  Some devs work on very specific parts of the tree, while
   some work on practically everything; neither should be shoehorned into
   an ad-hoc project structure.  Moreover, it should be easy to create new
   projects where needed (and remove them when they are not), which this
   proposal should enable.

2. By having the members choose their project leads periodically, the
   project leads are necessarily at least somewhat responsible (and
   hopefully responsive) to the project members.  This proposal has
   removed the list of responsibilities that project leads were supposed
   to satisfy, since hardly anybody has ever looked at the original list
   since it was written.  Instead the practical responsibility of a lead
   is "whatever the members require", and if that isn't satisfied, the
   members can get a new lead (if they can find somebody to take the job!).

3. If the council does a lousy job handling global issues (or has no
   global vision), vote out the bums.

4. Since everybody gets to vote for the council members, at least in
   principle the council members represent all developers, not just a
   particular subset.

5. An appeal process should make disciplinary enforcement both less
   capricious and more palatable.

6. This proposal doesn't help find inactive devs or projects.  It really
   should not be that much of a problem.  We already have a script
   for identifying devs who haven't made a CVS commit within a certain
   period of time.  As for moribund projects, if the project page isn't
   maintained, it's dead, and we should remove it.  That, too, could be
   automated.  A much bigger problem is understaffed herds, but more
   organization is not necessarily a solution.

7. The metabug project is a great idea.  Let's do that!  Adding a useful
   project shouldn't require "metastructure reform", although with the
   current system it does.  With this proposal it wouldn't.

8. This proposal has nothing to say about GLEPs.

Updates to this document
========================

Any major updates to this document (that is, those that change its
content rather than just fixing typos or adding small clarifications)
require a vote of all developers.  Eligible voters are all developers
at the time when the proposed update is published.  The vote passes if
both of the following conditions are fulfilled:

* The ratio of positive to negative votes is at least two to one, and
* the number of positive votes is no less than one quarter of the number
  of eligible voters.

References
==========

.. [#Metastructure_vote] Grant Goodyear, "Metastructure vote preliminary
   results", posted to ``gentoo-dev`` mailing list on 2005-06-14,
   Message-ID 20050614035141.GC15256\@dst.grantgoodyear.org
   (https://archives.gentoo.org/gentoo-dev/message/f5ab9ccca62a5d5e0b7b7ab0156f19b3)

.. [#Project_pages] https://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages

.. [#Council2007] 2007-02-08 council meeting
   (https://projects.gentoo.org/council/meeting-logs/20070208-summary.txt)

.. [#Council2009] 2009-07-20 council meeting
   (https://projects.gentoo.org/council/meeting-logs/20090720-summary.txt),
   confirmed on 2011-07-15
   (https://projects.gentoo.org/council/meeting-logs/20110715-summary.txt)

.. [#Council2013] 2013-02-12 council meeting
   (https://projects.gentoo.org/council/meeting-logs/20130212-summary.txt)

Copyright
=========

This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
International License.  To view a copy of this license, visit
https://creativecommons.org/licenses/by-sa/4.0/.
----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----
--- a/glep-0039.rst
+++ b/glep-0039.rst
@@ -1,14 +1,15 @@
 ---
 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>
 Type: Informational
 Status: Final
-Version: 2
+Version: 3
 Created: 2005-09-01
-Last-Modified: 2019-11-07
-Post-History: 2005-09-01, 2006-02-09, 2007-10-12, 2008-01-19
+Last-Modified: 2023-04-16
+Post-History: 2005-09-01, 2006-02-09, 2007-10-12, 2008-01-19, 2022-11-25,
+              2023-04-10, 2023-04-16
 Content-Type: text/x-rst
 Replaces: 4
 ---
@@ -21,6 +22,14 @@ Gentoo developers on 2005-06-14 [#Metastructure_vote]_.
 GLEP amended on 2006-02-09 to add the final bullet point to list B in
 `Specification`_.
 
+Updated by an all-developers vote on 2023-XX-XX:
+
+* Replace leaving council members by next in line [#Council2007]_.
+* Updating this document requires an all-developers vote [#Council2009]_.
+* Council members must be developers [#Council2013]_.
+* An inquorate council meeting cannot take any substantive action.
+* Drop hard requirement of yearly project lead elections.
+
 Abstract
 ========
 
@@ -116,10 +125,11 @@ A. A project is a group of developers working towards a goal (or a set
       that the information on the page is factually correct and not
       out-of-date.)  If the Wiki page isn't maintained, it is presumed
       dead.
-   *  It may have one or many leads, and the leads are
-      selected by the members of the project.  This selection must
-      occur at least once every 12 months, and may occur at any
-      time.
+   *  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.
    *  It may have zero or more sub-projects.  Sub-projects are
       just projects that provide some additional structure, and their
       Wiki pages are defined as sub-projects of the parent project.
@@ -138,6 +148,7 @@ B. Global issues will be decided by an elected Gentoo council.
       first election that number was set to 7 by acclamation.)
    *  Council members will be chosen by a general election of all
       devs once per year.
+   *  Council members (and their proxies) must be Gentoo developers.
    *  The council must hold an open meeting at least once per month.
    *  Council decisions are by majority vote of those who show up (or
       their proxies).
@@ -145,9 +156,16 @@ B. Global issues will be decided by an elected Gentoo council.
       two consecutive meetings, they are marked as a slacker.
    *  If a council member who has been marked a slacker misses any further
       meeting (or their appointed proxy doesn't show up), they lose their
-      position and a new election is held to replace that person. The newly
-      elected council member gets a 'reduced' term so that the yearly
-      elections still elect a full group.
+      position.
+   *  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.
    *  Council members who have previously been booted for excessive slacking
       may stand for future elections, including the election for their
       replacement. They should, however, justify their slackerness, and
@@ -155,7 +173,8 @@ B. Global issues will be decided by an elected Gentoo council.
    *  The 'slacker' marker is reset when a member is elected.
    *  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.  No substantive action can be taken
+      in any such meeting.
    *  Disciplinary actions may be appealed to the council.
    *  A proxy must not be an existing council member, and any single person
       may not be a proxy for more than one council member at any given
@@ -206,6 +225,19 @@ So, does this proposal solve any of the previously-mentioned problems?
 
 8. This proposal has nothing to say about GLEPs.
 
+Updates to this document
+========================
+
+Any major updates to this document (that is, those that change its
+content rather than just fixing typos or adding small clarifications)
+require a vote of all developers.  Eligible voters are all developers
+at the time when the proposed update is published.  The vote passes if
+both of the following conditions are fulfilled:
+
+* The ratio of positive to negative votes is at least two to one, and
+* the number of positive votes is no less than one quarter of the number
+  of eligible voters.
+
 References
 ==========
 
@@ -216,9 +248,20 @@ References
 
 .. [#Project_pages] https://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages
 
+.. [#Council2007] 2007-02-08 council meeting
+   (https://projects.gentoo.org/council/meeting-logs/20070208-summary.txt)
+
+.. [#Council2009] 2009-07-20 council meeting
+   (https://projects.gentoo.org/council/meeting-logs/20090720-summary.txt),
+   confirmed on 2011-07-15
+   (https://projects.gentoo.org/council/meeting-logs/20110715-summary.txt)
+
+.. [#Council2013] 2013-02-12 council meeting
+   (https://projects.gentoo.org/council/meeting-logs/20130212-summary.txt)
+
 Copyright
 =========
 
-This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
-Unported License.  To view a copy of this license, visit
-https://creativecommons.org/licenses/by-sa/3.0/.
+This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
+International License.  To view a copy of this license, visit
+https://creativecommons.org/licenses/by-sa/4.0/.
----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----

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

Re: [gentoo-project] Gentoo metastructure update (GLEP 39) voting now open

[Ulrich Mueller]

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

>>>>> On Mon, 24 Apr 2023, Ulrich Mueller wrote:

> Voting for the update of the Gentoo metastructure document (GLEP 39)
> is now open. The election is named "metastructure-2023".

> Login to dev.gentoo.org and use "votify --help" to get instructions
> on how to vote, verify, and submit your ballot.

> Voting closes at 2023-05-08 00:00:00 UTC (= end of day 2023-05-07).

I received a comment that it would be hard to figure out what this vote
is about. So here is a summary of the changes, with pointers to the
respective commits (where you'll find more information about these
changes):

* Replace leaving council members by next in line
  https://gitweb.gentoo.org/data/glep.git/commit/?id=c4df5974adab69d97f5118d0f7f693167a50581c

* Updating this document requires an all-developers vote
  https://gitweb.gentoo.org/data/glep.git/commit/?id=f94967967abc1f7f506d3ebbe9e23b8b7c05d1b9

* Council members must be developers
  https://gitweb.gentoo.org/data/glep.git/commit/?id=890b3b73a05bdbe3fdc171ab01b7428510737fe3

* An inquorate council meeting cannot take any substantive action
  https://gitweb.gentoo.org/data/glep.git/commit/?id=29bfaccbe91395059dacf47dfa9759283301aed2

* Drop hard requirement of yearly project lead elections
  https://gitweb.gentoo.org/data/glep.git/commit/?id=1dbe638f022c64bd29dfbe4d0a8bd55ca49d1549
  https://gitweb.gentoo.org/data/glep.git/commit/?id=e9027e1d081ea5737230985110dc044fce40039d

We will also update the title:
-Title: An "old-school" metastructure proposal with "boot for being a slacker"
+Title: Gentoo metastructure

Crossposting to -core this time to reach all developers, but please
reply to -project only.

Ulrich

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

[gentoo-project] Re: [gentoo-dev-announce] Gentoo metastructure update (GLEP 39) voting now open - 7 days left

[Jorge Manuel B. S. Vicetto]

[-- Attachment #1.1: Type: text/plain, Size: 1259 bytes --]

Fellow developers,

On 24/04/23 09:18, Ulrich Mueller wrote:
> Voting for the update of the Gentoo metastructure document (GLEP 39)
> is now open. The election is named "metastructure-2023".
> 
> Login to dev.gentoo.org and use "votify --help" to get instructions
> on how to vote, verify, and submit your ballot.
> 
> Voting closes at 2023-05-08 00:00:00 UTC (= end of day 2023-05-07).

This is a friendly reminder that we're nearing (at the end of the day) 
the half-period for this election voting.
This is our current turnout:

Eligible voters: 120
Submitted votes: 29
Pending votes: 2
Turnout: 24.167%
Pending Turnout: 25.833%

Therefore, please go ahead and cast your vote in the remaining week to 
ensure we have the best possible turnout for this election.
Also, don't forget to submit your vote (votify --submit 
metastructure-2023) or your vote won't count.

> Since mailing list archives aren't currently working (and I don't want
> to point to a third-party archive), I include the full text of the
> proposed new version and a diff relative to the active version again.
> 
> Regards,
> Ulrich

<snip proposed changes>

With best regards,
For the election team,

Jorge Manuel B. S. Vicetto
Gentoo Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[gentoo-project] Re: [gentoo-dev-announce] Gentoo metastructure update (GLEP 39) voting now open - 7 days left

[Ulrich Mueller]

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

>>>>> On Wed, 03 May 2023, Michael Orlitzky wrote:

[Please keep this thread in -project.]

>> This is a friendly reminder that we're nearing (at the end of the day) 
>> the half-period for this election voting.

> My options are "yes" and "no" but there's no indication of what I'm
> saying yes/no to.

> I'd wager that "yes" means update the GLEP but I'd really rather have
> it in writing before voting.

Quoting from my original posting, Message-ID: <u354pabaq_-_@gentoo.org>
(you can see it on marc.info [1], our own archives are currently down):

| Voting for the update of the Gentoo metastructure document (GLEP 39)
| is now open. The election is named "metastructure-2023".

Not sure why you think they wouldn't be clear, but the options mean:

- "yes" means that you vote for the update of the Gentoo metastructure
  document (GLEP 39).

- "no" means that you vote against it.

- "blank" means blank ballot. (And let's not start a discussion whether
  a ballot with the word "blank" on it is blank. :)

Ulrich

[1] https://marc.info/?l=gentoo-project&m=168232784705569&w=2

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

Re: [gentoo-project] Re: [gentoo-dev-announce] Gentoo metastructure update (GLEP 39) voting now open - 7 days left

[Michael Orlitzky]

On Wed, 2023-05-03 at 08:58 +0200, Ulrich Mueller wrote:
> > > > > 
> 
> > Voting for the update of the Gentoo metastructure document (GLEP
> > 39) is now open. The election is named "metastructure-2023".
> 
> Not sure why you think they wouldn't be clear, but the options mean:

Thanks. I've seen crazier things on ballots, and it wouldn't be the
first time that what was obvious to me turned out to be the opposite of
what was obvious to someone else. Better to be sure.