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

[Daniel Campbell]

I'll try to make points shorter where possible.

On 11/10/2016 04:01 AM, Rich Freeman wrote:
> On Wed, Nov 9, 2016 at 9:42 PM, Daniel Campbell <zlg@g.o
> <mailto: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?

The idea is if Comrel can't be held accountable and we're bound up in a
bunch of bureaucracy, and if we're suffering from manpower issues, it's
smarter to go lean and nix it entirely than try to revive or shape it
up. The actual actions taken against developers or users are already
handled by dedicated staff, and appeals would then, as usual, be heard
by Council. If nobody on Council had a hand in making the original
decision(s), then they're clear to judge the situation on its own merit.

> 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.

I hadn't considered those two, mostly because I've not seen or heard
of them going out of line. Overlap there should be disallowed as well,
as it can create a disproportionate amount of technical influence as
opposed to the social influence that we're discussing now.

> 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).

That's a good example. I think it's okay to have clearly defined roles
with cooperation between groups. For instance, if the trustees needs
some information that's stored on infra and doesn't have access, then
it makes sense for infra to help them out on that. If they're having
trouble working out the books, and someone happens to know something, I
see no problem there, either. But dual memberships isn't what I think is
healthy for Gentoo, its users, or its volunteers. It spreads our already
dwindling talent even further, and can prevent new blood from growing
into more important roles.

> 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.

The community is right to want trustworthy people in offices, but
it's not safe to concentrate power into the individuals who happen to
have the spare time to wear multiple big hats. Separating groups can
be a sort of "insurance", to protect a single person from affecting
too much. It's a sign, to me, that roles need to be either trained or
trimmed down. Another thing to worry about is the bus factor of any
given top-level group. If we need 24 people to have fully-functioning
top-level projects, then maybe we should be looking into motivating more
people to get into these positions rather than counting on long-term
members to simply take up more of the slack and add to their workload.
In short, asking ourselves why people don't want to step up and take
these positions, then correcting that.

In addition, wearing multiple hats can result in decisions or reasoning
that makes sense in one position, but not in the one that a given person
is acting in in that moment, e.g. worrying about trademark issues while
acting as a councilor. :P It's bound to be stressful, so why don't we
spread that work around?

> 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.

At no point should _any_ process be effectively a NOOP. That's a clear
sign of corruption and/or incompetence. If appeals are to be NOOP,
under any circumstance, then there isn't an appeal process, period. Any
overseeing group _must_ be prepared to take a second look at a case, or
take new evidence into consideration while reassessing a decision. If
a person is unwilling to admit that they might have made an oversight
somewhere, they're not fit to be deciding the fate of other developers.

We all mostly earned our positions as developers, and dismissing or
disciplining people without the willingness to understand the full
story devalues what it means to be part of Gentoo and, understandably,
may drive people away. I hope that if I were to be brought before some
overseeing group that they would do everything they could to understand
the full story, and reconsider in the event that new evidence arises.

As I've said before though, the existence of an overseeing group is the
wrong idea to begin with. To my knowledge, there's no overlap of staff
and council, so it could work if the separation was enforced.

> 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 see the reasoning in why that would happen, but I can't shake the
potential for risk. Smaller groups generally have fewer formalities and
fewer bureaucratic processes. We're experiencing a once medium-to-large
sized distro losing its manpower, slowly, and the processes that worked
for it when it was larger may start to claw away at whats left and leave
people stuck with multiple hats or empty projects.

When that happens to software, don't we treeclean it, with a last-rites
e-mail? People aren't software, sure, but if something is old,
unmaintained, and in _need_ of maintenance -- be it social group/process
or software -- we look at what it takes to make it better and push for
it to either get some attention or get rid of it.

If I understand correctly, you're saying that some attention, even if
it's from someone in another pivotal role, is better than no attention
at all. If that's the case, I think we're aiming too low. We need to
ask ourselves "Is comrel good for Gentoo?" "Is it improving Gentoo in
any tangible or measurable way?" "What do we lose by getting rid of it?"

Given that you indicated comrel hasn't been terribly active, and I've
not seen any cases where it's been necessary, I think it's prime for
removal. I'm open to being wrong about that, but current policy prevents
comrel being accountable to even simple questions like the ones I asked.
I hope it's understandable that some may not have faith or trust in such
entities and situations. Things are boiling down to "<group> is fine,
and do a good job; trust us, we're council." I hope I don't have to
explain what's wrong with that.

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

I appreciate that someone in the relevant groups is actually
communicating about it, even if we disagree. It shows that there's some
willingness to understand and maybe some sort of solution can be found
in common ground between us.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6