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

[Daniel Campbell]

On 11/09/2016 02:41 PM, Rich Freeman wrote:
> On Wed, Nov 9, 2016 at 4:56 PM, Roy Bamford <neddyseagoon@g.o> wrote:
>>
>> Since council do not appear to monitor comrel, how does council know
>> that they are doing a good job, or indeed that comrel is still active?
>>
>
> I'll agree that the current system relies on people who feel that
> Comrel isn't doing a good job to appeal their cases to the Council.  I
> completely support making changes to have more oversight of what is
> going on.
>
> However, it is probably worth noting that in the two cases that seem
> to have stirred up the pot, the Council DID exercise direct oversight
> on one of them, and in the other the person impacted has stated on the
> list that they do not believe that the Council would reverse the
> Comrel decisions, though they have not actually appealed.
>
> So, while I think some steps to have a bit more oversight are
> warranted, I'm really not expecting it to lead to any drastic
> revelations.  It isn't like Comrel is detaining people in Gitmo.  If
> there was some trend of inappropriate action I'm pretty sure those
> impacted would find a way to make their concerns known.  In the last
> month I've also heard expressed a desire both for Comrel to take more
> action to enforce the CoC, and for Comrel to take less.  The obvious
> pattern seems to be that when somebody is the one action is being
> taken against they tend to argue for less, and when somebody feels
> that somebody else is bothering them, they tend to call for more.  We
> had a recent appeal by somebody who was concerned that Comrel wasn't
> doing enough to take action against somebody, and the outcome at that
> time was that the Council felt that not enough time had elapsed for
> escalation to be warranted.  However, that brings up a fundamental
> problem with this sort of function, as with any other part of Gentoo
> it is volunteer based, and so people are going to be frustrated when
> the process moves slowly.  Certainly we should expect Comrel cases to
> be closed in an efficient manner just as we should expect package
> stable requests to be handled in an efficient manner, but the
> realities of having a volunteer-based system do collide with that.
>
> Personally my sense is that some quick wins that could be taken to
> increase Comrel oversight short of any huge structural changes would
> be:
> 1.  Have the Comrel lead approved by Council in the same manner that
> QA is, and the ability for Council to appoint interim leads when a
> confirmed lead doesn't exist.
> 2.  Ask Comrel to continue to publish anonymous stats on their
> activity level in general.
>
> I'm not suggesting this will fix everything, but it would be a start.
>
I agree that it'd be a good start. As you noted however, it's only a
start. We'd need to separate the powers entirely and prohibit staffing
overlaps if we want to take that part of our metastructure seriously. It
was a mistake to allow dual membership between council and comrel. Maybe
we should look at council<->trustees as well.

Ideally, we should end up with distinct groups that communicate with and
check on each other.

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