[Mageia-discuss] Mageia governance model draft

[Michael Scherer]

Le mardi 05 octobre 2010 à 17:03 +0200, Romain d'Alverny a écrit :
> On Tue, Oct 5, 2010 at 00:38, Michael Scherer <misc at zarb.org> wrote:
> > Le lundi 04 octobre 2010 à 15:26 +0200, Romain d'Alverny a écrit :
> >
> >> Each team will have to decide on itself, for the next two weeks:
> >>
> >>  * what is in the mentoring program exactly (for instance, Packaging team
> >>    has to take into account alternative packaging practices and explain
> >>    why/how it is expected to work in Mageia and how it could evolve);
> >
> > Hu ?
> > ( ie what "alternative packaging practice" ? )
> 
> Well, I guess that not all that enlisted in the packaging team are
> from the Cooker packagers group.
> 
> So there are a process, documents to agree all on so that the whole
> Team works well together. Process for working together (according to
> set standards - here in this case, I believe we should base all this
> on current Cooker practices and policies - but it's best that the Team
> itself decides on its own).

I also think we should use the cooker practices and policy. If we intend
to fork mandriva, we should start at this point. And once we have a
release, then we can discuss to change the policy.

> Discussing it further with founding members (mentoring program, how to
> apply), here are a few _important details_.
> 
> All teams discussion channels should be of public access (at least one
> place to join and follow what happens).

Well, I would even mandate that all discussions should be public, unless
very specific case. 

For example, I guess the security team will not want to discuss
everything in public, cause there is some embargo issues and so on. That
would be a valid case ( even if this then appeal for the whole
discussion of full disclosure ). But as the secteam could also take care
of regular updates coordination, and since bugfixes are not secret, and
should not be, I do not think that everything concerning secteam should
be private. I also think that for example a security bug who is know and
public have no reason to be secret on our side. 

And I think being public is important to avoid the alienating feeling of
facing a cabal and being ignored. People do not feel welcomed when we
say to them "you are a outsider, so we won't talk to you".


> Teams are made of at least two sub-groups (from a credentials point of view):
>  * "Apprentices" (people being mentored into the team - someone
> suggested "petit scarabée" as a label but...)
>  * and "Masters".

Well, as i said, I think master is not the ideal term. 

> Depending on Teams, there may be more than that (for instance, Web
> team may have apprentice, master, webmaster or a more specific role -
> vetoing what goes online for instance).
> 
> The idea is that Masters have voting power within the team (for
> decisions or leader election) and full rights on the infrastructure.

In the case of packagers, we still need to discuss ACLs on packages.
Even at mandriva, who has the most open policy I have seen in term of
commit rights ( when compared to Ubuntu, Gentoo, Fedora and debian ), we
had ACLs on some packages ( kernel, glibc, etc ).

So who decide the acl ? The board, the team, a technical comitee ? 

> Apprentices have no voice yet and less rights on infrastructure,
> provided they are being mentored. It's then up to Masters to decide if
> an Apprentice makes it to Master or not. That's the reality behind the
> mentoring process.
> 
> Now, to start the train, we've got to figure who will be first Masters
> and Apprentices. We expect everyone to be square on this and would
> like to start with the following rule, provided things go smoothly
> after.
>
> We are suggesting here for packagers only, that's a specific case.
> Each team should come up with its own agreement. Packaging Team
> Masters are those who are Cooker maintainers as of today. Others are
> Apprentices. Packaging team should focus then on build-system setup
> and mentoring process. Apprentices may become masters at any time,
> it's up for each team to decide.

As I said on irc, I kinda dislike calling a group "master" for
packagers. We are trying to reduce the gap between developers and users,
and as a developer, I am really bothered by such appellation because I
feel it put too much distance between me and non developers, and I think
we try to avoid that. 

More ever, some people think "I am not in the master group, this name
sound made for important people so I cannot do anything", and do not
feel empowered. 

And the equivalent group in Ubuntu is called MOTU, for Masters of the
universe. Which is either funny if you know the animated series, or a
little bit pompous otherwise. 

So as we do not want to appear to have copied on Ubuntu ( as this would
be quite the contrary regarding the packaging community ), I think the
name could be changed to a more factual and a less connoted name.

OTOH, I agree with the concept, as it worked well ( from my point of
view ) in cooker, and is kinda used everywhere ( with various level of
bureaucracy ) in free software world, especially in distribution world.


But given the size of the packaging volunteers group compared to the
current group able to mentor ( ie current cooker packagers who
volunteered ), I expect the backlog of people who want to become
packager to be huge for a long time, which itself bring some interesting
issues. 

> Should there be any conflict or gray-zone, don't get upset, just tell
> us and we will try to sort this out. In last resort, of course, the
> founding board will decide if needed.
> 
> Oh and we ought to setup mailing-lists for each team shortly.

Mailing lists for discussion, or mailing lists to contact ?

Ie, do we expect discussion of the teams to take place here, or to use
it as a big alias ?

If we expect discussion to happen, who will take care of subscription,
will this be "free for all" or not ?

How do we take care of subgroups ( ie the master/apprentice case that
you proposed ), does it map to the ml subscription or not ?

I would recommend a alias example-team at mageia.org to be used, so we can
contact the team ( maybe also example-team-leaders@ ), and only for
this, and have mailling list based on task, or group of team ( ie, -dev
would go for packagers and developpers , etc ). Or even something else
than a ml for discussion, after all.

And as a sysadmin of the project, I would also like to remind that I
will maybe propose to change ml naming ( because the mageia- prefix
should imho be removed ) and location ( ie, use ml.mageia.org domain, as
this would prevent clash in the future for various aliases ) and
software (ie something else than mailman, like sympa ) in a near future.
 
-- 
Michael Scherer