diff options
Diffstat (limited to 'zarb-ml/mageia-discuss/20101005/002224.html')
| -rw-r--r-- | zarb-ml/mageia-discuss/20101005/002224.html | 204 |
1 files changed, 204 insertions, 0 deletions
diff --git a/zarb-ml/mageia-discuss/20101005/002224.html b/zarb-ml/mageia-discuss/20101005/002224.html new file mode 100644 index 000000000..a59545479 --- /dev/null +++ b/zarb-ml/mageia-discuss/20101005/002224.html @@ -0,0 +1,204 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-discuss] Mageia governance model draft + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20Mageia%20governance%20model%20draft&In-Reply-To=%3C1286297739.29594.181.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002221.html"> + <LINK REL="Next" HREF="002225.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-discuss] Mageia governance model draft</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20Mageia%20governance%20model%20draft&In-Reply-To=%3C1286297739.29594.181.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-discuss] Mageia governance model draft">misc at zarb.org + </A><BR> + <I>Tue Oct 5 18:55:39 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="002221.html">[Mageia-discuss] Mageia governance model draft +</A></li> + <LI>Next message: <A HREF="002225.html">[Mageia-discuss] Mageia governance model draft +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2224">[ date ]</a> + <a href="thread.html#2224">[ thread ]</a> + <a href="subject.html#2224">[ subject ]</a> + <a href="author.html#2224">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le mardi 05 octobre 2010 à 17:03 +0200, Romain d'Alverny a écrit : +><i> On Tue, Oct 5, 2010 at 00:38, Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-discuss">misc at zarb.org</A>> wrote: +</I>><i> > Le lundi 04 octobre 2010 à 15:26 +0200, Romain d'Alverny a écrit : +</I>><i> > +</I>><i> >> Each team will have to decide on itself, for the next two weeks: +</I>><i> >> +</I>><i> >> * what is in the mentoring program exactly (for instance, Packaging team +</I>><i> >> has to take into account alternative packaging practices and explain +</I>><i> >> why/how it is expected to work in Mageia and how it could evolve); +</I>><i> > +</I>><i> > Hu ? +</I>><i> > ( ie what "alternative packaging practice" ? ) +</I>><i> +</I>><i> Well, I guess that not all that enlisted in the packaging team are +</I>><i> from the Cooker packagers group. +</I>><i> +</I>><i> So there are a process, documents to agree all on so that the whole +</I>><i> Team works well together. Process for working together (according to +</I>><i> set standards - here in this case, I believe we should base all this +</I>><i> on current Cooker practices and policies - but it's best that the Team +</I>><i> itself decides on its own). +</I> +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. + +><i> Discussing it further with founding members (mentoring program, how to +</I>><i> apply), here are a few _important details_. +</I>><i> +</I>><i> All teams discussion channels should be of public access (at least one +</I>><i> place to join and follow what happens). +</I> +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". + + +><i> Teams are made of at least two sub-groups (from a credentials point of view): +</I>><i> * "Apprentices" (people being mentored into the team - someone +</I>><i> suggested "petit scarabée" as a label but...) +</I>><i> * and "Masters". +</I> +Well, as i said, I think master is not the ideal term. + +><i> Depending on Teams, there may be more than that (for instance, Web +</I>><i> team may have apprentice, master, webmaster or a more specific role - +</I>><i> vetoing what goes online for instance). +</I>><i> +</I>><i> The idea is that Masters have voting power within the team (for +</I>><i> decisions or leader election) and full rights on the infrastructure. +</I> +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 ? + +><i> Apprentices have no voice yet and less rights on infrastructure, +</I>><i> provided they are being mentored. It's then up to Masters to decide if +</I>><i> an Apprentice makes it to Master or not. That's the reality behind the +</I>><i> mentoring process. +</I>><i> +</I>><i> Now, to start the train, we've got to figure who will be first Masters +</I>><i> and Apprentices. We expect everyone to be square on this and would +</I>><i> like to start with the following rule, provided things go smoothly +</I>><i> after. +</I>><i> +</I>><i> We are suggesting here for packagers only, that's a specific case. +</I>><i> Each team should come up with its own agreement. Packaging Team +</I>><i> Masters are those who are Cooker maintainers as of today. Others are +</I>><i> Apprentices. Packaging team should focus then on build-system setup +</I>><i> and mentoring process. Apprentices may become masters at any time, +</I>><i> it's up for each team to decide. +</I> +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. + +><i> Should there be any conflict or gray-zone, don't get upset, just tell +</I>><i> us and we will try to sort this out. In last resort, of course, the +</I>><i> founding board will decide if needed. +</I>><i> +</I>><i> Oh and we ought to setup mailing-lists for each team shortly. +</I> +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 <A HREF="https://www.mageia.org/mailman/listinfo/mageia-discuss">example-team at mageia.org</A> 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 + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002221.html">[Mageia-discuss] Mageia governance model draft +</A></li> + <LI>Next message: <A HREF="002225.html">[Mageia-discuss] Mageia governance model draft +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2224">[ date ]</a> + <a href="thread.html#2224">[ thread ]</a> + <a href="subject.html#2224">[ subject ]</a> + <a href="author.html#2224">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-discuss">More information about the Mageia-discuss +mailing list</a><br> +</body></html> |