Re: [gentoo-project] [RFC] Triumvirate in Gentoo

[Rich Freeman <rich0@gentoo.org>]

(Keep in mind that these aren't intended as "hard" objections - just
trying to flesh this out a bit.)

On Thu, Jun 4, 2020 at 11:19 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Thu, 2020-06-04 at 09:12 -0400, Rich Freeman wrote:
> > On Thu, Jun 4, 2020 at 3:15 AM Michał Górny <mgorny@gentoo.org> wrote:
> >
> > 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.
>
> I dare say that one of them can make decisions if the two other don't
> object to them.  So it's mostly a matter of establishing an agreement
> between the three whether they want to get involved every time,
> or approve deferring specific kind of decisions to one of them.
>

Ok.  I agree that this is how this would normally work, but if there
is disagreement it is 2/3 majority rules.

I'll get to intentional game-playing at the end, but let's assume a
completely innocent scenario.

Imagine Joe is great with financials and has interest in the org lead
role, and there isn't much other interest in the job.  The community
is happy with his work in the org lead role.  However, due to the fact
that delegation to the tech lead is only by mutual agreement, Joe ends
up having a bit of an extra influence on the tech side of the distro
even though nobody really wants him in that role.  If nothing else he
has way more of a voice in the leadership team than an average
dev/etc.

You could argue that this is a feature or a bug depending on your
perspective.  Joe is putting in a lot of work, so maybe a bit of extra
bikeshedding should be a perk.  On the other hand, why should Joe be
allowed that role?  And of course Joe and the people lead might think
we're about to make a really stupid tech decision and override the
tech lead.

Not suggesting this is a show-stopper - just something to consider.

> > 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...
> >
>
> I don't really understand why you assume that such a thing would happen.
> Did we ever really have someone *that* unprofessional on the Council or
> Trustees to push puny personal agenda over the best interest
> of the distribution?  I don't see any possible change here.  The same
> problem can happen whether we're talking of 1, 3, 7 or 12 people
> in charge.  Well, you could even argue that the latter is even more
> possible because the responsibility is diluted, while if there's just
> one responsible person, then the full blame goes to that person.

I'm just thinking about human nature here.  Maybe it is concerning
systemd.  Or maybe it is concerning the Code of Conduct or Social
Contract.  There are always going to be contentious issues that are
often only semi-technical in nature and you can't always solve it with
a USE flag.

One of the differences today is that we separate the role of SME from
the role of decider.  You can have a board that is just focused on
direction and overall policy/strategy, but they aren't the ones
leading QA.  You can have a board of directors who oversees
everything, but they can appoint a Treasurer.  Campaigns for
Council/Trustees in the past certainly have touched on ideological
issues (role of comrel/CoC and level of enforcement, Foundation vs
umbrella, etc).

In this model the decider is more of an SME.  It is more of a
technocracy.  The problem is that how do you vote to support having an
umbrella org if the most competent person to actually make sure the
taxes get filed wants us to run our own Foundation?  There is less
separation of policymaking from execution this way.

I think the result is that ideology will still end up dominating, and
instead of the most competent SME for tech/people/org you end up with
3 people who have the views everybody likes the most who will just
appoint other people do do the tech/people/org, which basically makes
it no different from what we have now.  I'd argue that instead of 3
separate elections it might be better to just have one election and
take the top 3 that way, and not give them titles - it just turns into
a combined Council/Trustees of 3.

The problem with having 3 separate elections is the
first-past-the-post issue: if 55% of the community is pro-systemd you
end up with 3 pro-systemd candidates, instead of maybe more of a
diverse mix with a majority in one direction.

In an ideal world I agree that this wouldn't be a problem, but I'm
just thinking about human nature here.  And I'm not saying people are
even being greedy - they just want to see their viewpoints
represented.

In this sense, the disagreement across Council/Trustee members maybe
should be seen as more of a feature and less of a bug.  Sure,
decisions would be easier if they all agreed, but that also means that
decisions would be easier even if 40% of the community strongly
disagreed with them.  That spirit of independence in these bodies
largely reflects the attitude of the Gentoo community as a whole.

Again, this isn't meant to be some argument that we absolutely
shouldn't do it this way.  My intent here is to raise some things to
think about.  There are some cons that go with the pros, and we should
just be aware of them.  I'm not saying they all have to be mitigated
in the design, though when straightforward to do so maybe some could
be.

-- 
Rich

-- 
Rich