[Mageia-discuss] Mageia governance model draft

[Romain d'Alverny]

On Tue, Oct 5, 2010 at 18:55, Michael Scherer <misc at zarb.org> wrote:
> Le mardi 05 octobre 2010 à 17:03 +0200, Romain d'Alverny a écrit :
> 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.

Makes sense but I would suggest you (whole team) already take into
account questions/improvement suggestions while this first release
(not to apply them at once, but to answer and prepare post-release
work and discussions about them).

I'm sure we all know the two imperatives here:
 - setting up the build system and pushing the first release for the 3
coming months; using the stable existing policies of Cooker;
 - advocate, debate, discuss, develop and improve policies.

(and, actually, that's valid for almost all other teams as well -
sometimes it may be worse, when there's just no policy yet)

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

For this kind of discussion/decision, the rule is the same (be it for
packagers or others):
 - team discusses; and either:
   - reaches an agreement, then inform the Council & Board, then apply;
   - can't reach such an agreement, then escalates the issue to
Council, then Board, who will listen, ponder, decide (or return the
discussion to the team).

Here, provided the Council is not yet constituted, the Board will
directly handle here.

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

I believe we all understand the idea behind it but the wording does
not match everyone's picture.

It's about having a committed/granted role within the team; or not.
Indeed, there is a difference between someone who has spent some time
in a team, has been recognized by her peers, gets an advanced commit
right for some specific packages, has a say some team-specific
policies, and someone who has not. And there are degrees.

There's a difference, but that doesn't make a distance. Here, it's a
matter of skills, commitment recognized and approved by peers. We have
to materialize this with roles, name these roles and explain why/how
they interact.

All the rest is a matter of how you and non-developers interact; can
be distant, or not.

Please note that it's not a master/slave or dictator/executant
relationship. It's about, as Ahmad said, about experience within the
team, regarding policies, processes; and about acquiring this
experience. See http://en.wikipedia.org/wiki/Apprenticeship somehow.

It could be, indeed, jedi/padawan, "the great beatle"/"young
grasshopper", whatever. We can find a better naming scheme here too
(of course, it's open); but I'd rather use that scheme now and
demonstrate within the cominig months what it is about (and improve it
with time) instead of spending yet another 60-posts exchange to nail
one down.

(and, it's not just about packagers; it's a generic term to find for
all teams - in that there are three roles: passers-by/followers,
apprentices and masters - will be too in developers, web,
communication, marketing, design, QA, doc, users teams)

Again, Ahmad nailed it down very well. It's not about building some
"old timers" clique that would oppose new comers. It's about making a
consistent team that manages consistent processes and evolves in a
concerted way, with everyone, but more importantly with its own
members. And the mentoring process is something that should be done in
a matter of 1, 2, 3 months at most. Maybe more, maybe less, depends on
the team. There's no numerus clausus, provided there are enough
mentors.

That, too, doesn't prevent other people to contribute within the team
(how would one become an apprentice otherwise?).

And that too, doesn't make it unreachable to anyone who wants to go
there; quite the contrary, that's why we insist on this mentoring
process being defined by/for each team. It's a matter of goodwill,
patience, work and fun.

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

A "master" is not important but in what she masters. Through my time
in schools and universities, most doctors and masters I have met were
neither important or distant in that they didn't take some vain and
inappropriate pride in their title. They were (are) true masters in
many ways still.

Attitude, kindness speak way more than a title.

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

That's a counter argument as well. Because they use the word "master"?
Wait then, there are a lot of other words they use over there. So
what? They may even have had good ideas in other areas; what should
prevent us from inspiring/taking from others' good ideas? (be it
Ubuntu or anyone else)

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

Indeed. That's tricky. What's crucial is to face this with calm and
determination to find a common working ground.

>> Oh and we ought to setup mailing-lists for each team shortly.
> [...]
> If we expect discussion to happen, who will take care of subscription,
> will this be "free for all" or not ?

Free for all.

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

Everyone subscribed can post to the list.

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

Mailing-list subscription should be free. We can expect
followers/attendees, "apprentices" and "masters" to manage their ml
subscription by themselves here.

Hence, provided there is a welcome page for the team explaining how to
join the list, or contacting briefly some people in the team (through
IRC, mail or a drink), I don't see the point to have a
contact-specific ml or alias.

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

Yep. That's a whole other topic though.


Thanks for reading, thanks a lot for stating if you fear/wonder if you
misunderstand something, we are in a building process here and your
feedback is valuable in that it helps the whole thing to be better
designed and tried.

Cheers,

Romain