public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-project <gentoo-project@lists.gentoo.org>
Subject: Re: [gentoo-project] [RFC] Triumvirate in Gentoo
Date: Thu, 4 Jun 2020 09:12:21 -0400	[thread overview]
Message-ID: <CAGfcS_nucxax=gfyxKqwEqOHh-p=Dm_8gXnW+hEv-6V+v1n6Jw@mail.gmail.com> (raw)
In-Reply-To: <31f6f5b574e0818a8fca3549e696ea18793c22ab.camel@gentoo.org>

On Thu, Jun 4, 2020 at 3:15 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> 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.
>

A few thoughts:

1.  There may be some legal challenges with the Foundation around
this, but I don't want to elaborate on this.  Many are obvious.

2.  If the goal is to ultimately elect these, I would just have the
election vs having them initially be some particular lead.  However, I
think what you say is still useful in terms of thinking of the sort of
role.  The problem is none of these leads are popularly elected today
and were never intended to unilaterally run the org, so an initial
election probably makes sense.

3.  Do all decisions require a majority of the 3, or will these
individuals have their own scope?  Will a new technical GLEP just be
approved by the "tech lead" or all three?  Could the two non-tech
leads override the tech lead on a tech decision?  Obviously the goal
is collaboration but presumably you want this to solve situations
where collaboration already fails.  I won't go on forever but I could
see challenges either way.

4.  How does accountability work?  Are we going to get volunteers who
are going to be competent and accept singular accountability without
compensation?  We struggle to fill Trustee slots and their
responsibilities are somewhat nebulous/dilute.  Will somebody
competent want to be singularly responsible for all fiscal problems
without compensation?  Don't get me wrong - singular accountability
works well in practice but usually these roles are well-compensated.
I could see this being a bigger problem with the org lead role.

5.  I could see a lot of bleed-over.  If you want to stack the
leadership with pro/anti-emacs members, why would you limit that to
only the technical role?  Obviously I'm more concerned with more
timely issues but we all know of a bunch of hot-button topics where
top-down control can be used to push an agenda.  So you could end up
with an org lead who cares little about the financials simply because
they have the right position on the hot topic of the day.  Today these
jobs are more delegated so that the elected board can represent the
community but delegate the actual work to people who are more focused
on the actual work.  Sure, you could blame the voters for this sort of
problem, but we already know how people tend to vote so we're not
entirely blame-free if we set it up this way...

Not really meant to suggest that this doesn't have merit, because I
think it does have a lot of merit.  This is more food for thought...

-- 
Rich


-- 
Rich


  parent reply	other threads:[~2020-06-04 13:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04  7:15 [gentoo-project] [RFC] Triumvirate in Gentoo Michał Górny
2020-06-04 12:41 ` Haelwenn (lanodan) Monnier
2020-06-04 12:54   ` Michał Górny
2020-06-04 13:12 ` Rich Freeman [this message]
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='CAGfcS_nucxax=gfyxKqwEqOHh-p=Dm_8gXnW+hEv-6V+v1n6Jw@mail.gmail.com' \
    --to=rich0@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