Re: [gentoo-project] Groups under the Council or Foundation: the structure & processes thereof

[Daniel Campbell]

On 10/12/2016 04:30 PM, Robin H. Johnson wrote:
> TL;DR: move comrel, infra, PR to Foundation. Have strict(er) application
> of policies to them in line with their powers.

That's a surprising idea, and invites questions to consequences.
>
> I've deliberately broken the thread, but also include some history in
> the origins of the groups.
>
> On Mon, Oct 10, 2016 at 11:05:39PM +0100, Roy Bamford wrote:
> ...
>> Council have an annual mandate from the body of Gentoo devs.
>> Devrel had a mandate from council but that's not been renewed since
>> 2007, unless I missed a vote somewhere.
> ...
>> On 2016.10.07 16:09, Rich Freeman wrote:
> ...
>>> I think it makes far more sense to have Comrel vetted by the Council.
>>> If you don't trust somebody to be wielding that power, you shouldn't
>>> put them on the Council.
>> That addresses lots of concerns all in one go.
>>
>> Comrel get their annual mandate. The community know that council
>> are peeking into comrel to see if its still alive and that its still
>> operating as intended.  Its more work for council to do the job
>> properly.
>>
>> It also means that council members would see things that they
>> don't usually see unless there was an appeal.  Thus council can
>> provide a general assurance to the community about all the good
>> things comrel do that are currently privileged.
> To make a radical suggestion, I'm wondering if it might be considered to
> put some organizational group responsibilities under the Foundation
> instead, while to establish others formally of the Council.
> In some parlance, they might be considered as appointed/'hired' staff or
> committee members of the management bodies, while the bodies themselves
> remain elected.
>
> I've used 'contributors' as a descriptor below, because the CoC should
> be applies to both developers & users & non-users alike: all
> participants in any Gentoo-associated media, mailing lists, IRC
> channels, message boards etc.
>
> I've also tried to avoid using our existing term 'project', because some
> of the group responsibilities do not fit well into the project structure
> of GLEP39.
>
> I joined Gentoo in 2003, and a lot of the groups were already in
> existence, whilst only a few came later.
> - PR, Devrel, Infra are some of the oldest groups inside Gentoo:
>   they were listed in GLEP-4 as of 2003/06/30, as pre-existing entities
>   within the distribution. GLEP-4 made the groups them into
>   top-level-projects.
> -- Recruiters were an offshoot from the original Devrel:Newdev sub-project
> -- QA is also present in that document, but bears little resemblance to
>    the original group.
> - Foundation's origins (2004, 2007 all-new) are in ensuring that the
>   distribution is organizationally (legally & financial) sound.
> - Council's origins (2006, GLEP39) are in handling global issues and
>   those that cross GLEP39-project boundaries, both to ensure that the
>   distribution is technically sound.
>
> The establishment of the Council & GLEP39 mostly placed all of the
> existing groups as reporting to the Council, and therein problems have
> ultimately arisen. As noted by the fact that Devrel's mandate wasn't
> formally renewed.
>
> The responsibilities of some of the older groups can & do cross the
> technical/organizational boundaries, whilst others fall clearly into one
> side.
> - Infra gets sponsorship & Foundation funds to ensure hosting & services
>   keep running for the distribution's needs. Legal compliance that what
>   we run complies with laws.
> - PR promotes the distribution (via the banners for conferences,
>   merchandise), trademark usage questions often come here.
> - QA is a technical function, and clearly belongs to the Council.
>   However it's enforcement powers suggest that it might not be just a
>   GLEP39-project.
> - ComRel falls more into the side of organizational than technical:
> -- CoC issues with contributors
> - Recruiters have historically functioned mostly to ensure that new
>   contributors seeking to become developers are technically sound, and
>   to a lesser degree that they are a social fit for the distribution.
>
> So how do we improve things?
> 1. Move some of the groups, to the Foundation.
> 2. Clearly define&change their rules of group formation.
> 3. By accepting roles/responsibilities in these groups, a contributor
>    MUST agree to uphold strong principles (eg, rules for employees in an
>    organization are stricter/more-binding than those of customers, and
>    strongly derived from federal/state laws & regulations).
>
> Anybody should be able to apply to join the groups, but their joining
> should be vetted by some level: The council members (possibly in
> collaboration with the Foundation trustees) might wish to appoint, for
> limited terms, group leaders and/or members. It's also possible the
> group leaders in themselves might have a role in suggesting new members
> to Council or the Foundation for approval.
>

This seems pretty well thought-out so far. What measures does the
Foundation have to protect itself from liability, in the event someone
"goes rogue" or otherwise abuses their power? Would it be similar to an
employer, where the usual method to deal with things is removing someone
from a given position?

When something is headed by the council, or the council itself acts out
of line, our recourse is voting a new council. In my search I did not
find any mention of the ability for the community to recall an election,
so we would need to wait for the next election to act on something.

For the foundation, I assume it's the Trustees and President who make
decisions; right? With meeting minutes, parliament-style proceedings,
etc? I'm asking this mostly to ensure that moving a pivotal group to the
Foundation would result in better group accountability rather than cart
blanche to do as they please.

One thing that concerns me also is the appropriateness of consequences.
If someone acts out of line as comrel, for example, would the Foundation
opt to strip them of just the comrel role (which seems fair), or remove
their Foundation membership entirely (a bit too extreme imo)? Perhaps
that would be covered under one of your bullet points.

We have a chiken-and-egg problem wrt council and comrel. If comrel is
part of the Foundation, but enforces the CoC laid down by the Council,
that seems like an odd combination. Would the Foundation be taking
control of the CoC at that point, or would it actually be beneficial for
the Council to remain in charge of the CoC despite enforcement being
part of a different body?

I like the idea of anyone being able to join; that's close to the
Foundation itself, and encourages people to get involved in what they
care about. It seems that the Foundation already has a set of policies
and procedures that lend itself well to being a governing body, such as
vetting, voting via trustees, and accountability that's kept separate
from everyday duties as a developer. This could lead to developers being
disciplined by one group but still able to contribute to fields where
they haven't created trouble.

Are there any plans to write up a GLEP, wiki page, IRC channel...? Count
me as interested.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6