Re: [gentoo-project] Representation of Gentoo on third-party platforms

[Rich Freeman]

On Wed, Nov 9, 2016 at 9:42 PM, Daniel Campbell <zlg@g.o> wrote:
> I would vote in favor of language along these lines:
>
> "Gentoo developers may sit for a maximum of one (1) office between the
> Community Relations, Council, and Trustees projects. Should a developer
> run for and win election for more than one office, they are to choose
> which office they favor, with the next runner-up assuming the office not
> claimed. This restriction enables officers to focus solely on their area
> of concern and prevents manipulation or abuse of power. Each project may
> impose its own requirements for membership, but no developer may be
> allowed membership to more than one of the prior mentioned groups."
>
> It's not what I think is ideal (no Comrel at all, leaving that job to
> Staff), but I think it creates an environment that is more accountable
> and less likely to cause further problems in the future.

If there is no Comrel wouldn't that be leaving the job to Council?  Surely
you're not suggesting that random IRC ops should have the rights to kick
random developers entirely from the project (IRC ops already do all the
things you seem to want them to do).  If there were no Comrel, wouldn't
that be equivalent to a Comrel that had 100% overlap with Council and no
appeals?

Setting that aside, you also left out QA and Infra, which are the other two
special projects.  QA has most of the powers that Comrel has that people
tend to get concerned with (cutting off commit access, unilaterally
imposing restrictions on tree policy, with the same appeal to Council as
Comrel, though it operates more openly).  Infra effectively has a lot of
power though it mainly serves to execute policy more than anything else.

Note that Council members are already not allowed to be Trustees (a policy
I've publicly disagreed with a few times, somehow managing to not get
kicked out for :) ).

So, while I'm not entirely opposed in concept to what you're saying, it
does raise a practical issue, which is why I've tended to be reluctant to
embrace these suggestions when they come up.  We have 7 council members and
trustees.  Let's say that we want 5 members of QA and Comrel (those don't
have fixed numbers).  You're now up to 24 people who have to hold mutually
exclusive positions.  That is probably 10% or more of the truly active
developer population (I don't have a problem with having a long tail of
devs who make small positive contributions, but they're probably not going
to be staffing the Trustees).  On the one hand spreading out the jobs in
theory gives people more time to devote to each.  In practice it tends to
involve giving more roles to people who are actually less interested in
doing them.  At points in the past we've actually struggled to fill Trustee
slots (I think we've gotten down to around 5-6 vacancies at points), and
for several of the past elections they've run unopposed.

So, by putting a restriction on how positions are filled, you potentially
block positions from being filled by whoever is best qualified and
interested in spending the time.  For example, Robin has been doing
excellent work for the last few months trying to get the Foundations books
in order, but he's also on Infra, and fairly vital there from what I've
seen.  If those slots were mutually exclusive then one team or the other
would be deprived of his contributions, at least in the full capacity
(maybe he could serve the Foundation without being a formal Trustee, but
let's be honest and consider that people who have official titles probably
do tend to give it a bit more sustained effort).

In the case of Comrel, Trustees, Infra, and Council the positions also
involve access to sensitive information, such as financial data, bank
accounts, root passwords, or disciplinary actions.  The community is going
to want to have people who are well-trusted in these roles, and the more
bodies you want to put in them the harder it is to find people who are
well-accepted by the community.

While I wouldn't want the entire show run by 1-3 people, I don't think
we're at risk of some kind of coup if we only have 10 people running the
show and not 24.

Checks and balances sound nice in theory, but they tend to work by blocking
any action in the absence of agreement.  Maybe when you're talking about
going to war or locking people up in prison that makes more sense (though,
honestly I think the US has some of the strongest checks and balances of
any government and in practice it is very dysfunctional, with branches of
government tending to bend the rules just to get anything done, and
constant stalemate).  With a cooperative distro where people have the
freedom to fork it if it gets out of hand, I'm not convinced that all the
checks are helpful.  Do we really want a Comrel that goes off and puts
developers through a ton of rigor while they fear for their commit access,
then kicks them out, only to have the Council immediately reverse the
action because they're completely unaligned?  I would think that we'd want
a single consistent set of policies so that most appeals are just NOOPs
because the original group did its job.  This is how QA largely operates;
in theory anybody can appeal any QA decision to Council, but in practice it
rarely happens because the two groups communicate well and QA tends to
generally follow the policies the elected Council is setting (and they
really reflect sentiment of the larger community anyway).

There is another practical matter here.  One of the main ways that Council
members end up in roles like QA/Comrel is because of some problem in these
teams, such as inactivity, or understaffing.  A Council member might step
in and act as an interim lead to try to bring new life into the body.
Ideally they find somebody to replace them and then leave, but that doesn't
always happen.  At the very least doing this requires temporary
dual-membership, and sometimes it has to be sustained until somebody
actually steps up.

I'm not saying I'm strongly opposed to your suggestion.  I just want to
point out that it has its downsides and I'm not convinced that it would
improve things as a result.

-- 
Rich