public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-project <gentoo-project@lists.gentoo.org>
Subject: [gentoo-project] [RFC] Triumvirate in Gentoo
Date: Thu, 04 Jun 2020 09:15:37 +0200	[thread overview]
Message-ID: <31f6f5b574e0818a8fca3549e696ea18793c22ab.camel@gentoo.org> (raw)

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

Hello, everyone.

This is something I wanted to discuss back in April but due to the peak
of covid pandemic I've delayed it.  Today things seem to be improving
a bit, at least in Europe, so I'd like to bring it up now, especially
with the elections coming soon.


Gentoo is technically led by two bodies -- the Council and the Trustees.
While this somewhat works for many years, people have repeatedly pointed
out that it's far from perfect and that it is preventing Gentoo from
gaining more popularity.  Some of them are looking into the times of
BDFL with longing, others are considering it the worst thing ever. 
Nevertheless, there are problems with the current state of things.

Firstly, we have two leading bodies and still no clear distinction
between their roles.  Some developers agree on split being here, some
developers put it elsewhere but in the end, nothing has been really
decided.  From time to time one of the bodies tries to push their border
forward, then backs down and we're back where we started.

Secondly, for historical reasons the both bodies are elected by two
electorates that only partially overlap.  Surely, today the overlap is
reasonable but is there any real reason for different people to elect
both bodies?  In the end, it is entirely possible for one body to
arbitrarily change their electorate and made it completely disjoint.

Thirdly, large governing bodies don't really work.  Instead of having
one consistent vision of Gentoo, we have 12.  What we get is a semi-
random combination of parts of their visions that just happened to hit
majority in their votes.  It gets absurd to the point that a body can
make half-way decisions just because first half passed vote
and the second didn't (remember closing -dev but leaving -project
open?).

Compromises are sometimes good and sometimes horrible.  If one dev wants
to paint the bikeshed red and another one blue, mixings the two colors
doesn't really get either what he wants.  You just get a third color
that nobody is happy with, and in the best case you could say that
neither of them got what he wanted.


BDFL is not a perfect solution either.  While having one has the obvious
advantage of having a single consistent vision for the distribution,
giving absolute power to a single person creates a fair risk of abuse. 
This is not something most of Gentoo devs would agree to.


All that said, I'd propose to meet in the middle -- following
the ancient tradition, establish a triumvirate in Gentoo.  It would be:

1. Technical lead -- a person with exceptional technical talents that
would build the vision of Gentoo from technical perspective, i.e. make
a distribution that people would love using.  Initially, this role could
be taken by the QA lead.

2. Social lead -- a person with exceptional social skills that would
build the vision of Gentoo from community perspective, i.e. make
a distribution that people would love contributing to.  Initially, this
role would taken by the ComRel lead.

3. Organization lead -- a person with (exceptional) business skills that
would take care of all the financial and organizational aspects of
Gentoo, i.e. make a distribution that sustains.  Initially, this role
would be taken by the Foundation president.

Three seems to be a very good number -- on one hand, it's more than one,
so the others can stop any single one from getting absolute power.
On the other, it's small enough for them to be able to actively work
together and directly establish a common set of goals (i.e. via
an agreement rather than a majority vote).


WDYT?

-- 
Best regards,
Michał Górny


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

             reply	other threads:[~2020-06-04  7:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04  7:15 Michał Górny [this message]
2020-06-04 12:41 ` [gentoo-project] [RFC] Triumvirate in Gentoo Haelwenn (lanodan) Monnier
2020-06-04 12:54   ` Michał Górny
2020-06-04 13:12 ` Rich Freeman
2020-06-04 13:16   ` Joonas Niilola
2020-06-04 15:01     ` Brian Dolbec
2020-06-04 15:20       ` Michał Górny
2020-06-04 15:19   ` Michał Górny
2020-06-04 16:08     ` Rich Freeman
2020-06-04 17:32 ` Adam Feldman
2020-06-04 19:49   ` Michał Górny
2020-06-04 20:35     ` Adam Feldman
2020-06-09 11:53   ` Lars Wendler
2020-06-04 19:01 ` Aaron Bauman
2020-06-04 19:47   ` Michał Górny
2020-06-04 20:15     ` Aaron Bauman
2020-06-05  1:55 ` Alec Warner
2020-06-05  5:16 ` Michał Górny
2020-06-05  7:53   ` Ulrich Mueller
2020-06-07 12:44   ` Stefan Strogin

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=31f6f5b574e0818a8fca3549e696ea18793c22ab.camel@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-project@lists.gentoo.org \
    /path/to/YOUR_REPLY

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

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