Here is the proposed governance structure for Mageia as of October, 4th 2010.
Please have a look at http://mageia.org/g/images/organisation.png while reading this document, which is also displayed below:
There are four major entities in Mageia: the Community at large, Teams, the Community Council and the Board.
The Mageia Board is in charge of:
- keeping and advocating the project values, mission & direction;
- communication & resources management;
- Council and Teams coordination;
- conflict resolution;
- holding the Mageia.Org association administrative role (money, property, etc.).
The Mageia Board is made from 3 up to 12 people. We start with 6, chosen among the founding team people. We will adjust the Board actual size if needed.
It is elected by third, from and by the Mageia association active members at every general assembly, once a year (we expect to hold the first one at the coming FOSDEM, in February 2011 in Brussels, Belgium).
We expect those to be elected to be recognized by their peers for being excellent leaders and listeners.
The Board will have a public and a private mailing-list; both will be archived; only the current Board members will be subscribers.
It will hold a public online progress meeting (IRC) every two weeks; only Board members and special attendees can speak; meeting notes will be published on the wiki.
It will publish regularly on the blog, in the mailing-list, when/where appropriate.
Mageia association active members
Those are the ones who can elect the Mageia Board from other active members.
How does one become an active member? either:
- being a founding member;
- having been elected by the board for services provided to the project;
- having been elected to the Mageia Community Council the year before.
There are other types of members of the association: honorary ones, benefactors (commercial sponsors, for instance), donators. We will detail their status later, but these have no voice in the election process (but a consultative one).
How does one lose this status? either:
- deciding so and asking the Board to be removed;
- doing something really wrong to the project;
- not attending (or not being represented) at two consecutive general assemblies; she then become honorary member of the association.
Note that the "active" thing is only related to the legal definition in the association status. :-) You may not be such a member and still be very active in the project.
Apart from being eligible at the Board and having a voice for the General Assembly, there's no other specific attribute to these members; they may still be part of the Council or in any Team.
Mageia Community Council
The Council is in charge of:
- project day-to-day management, planning, coordination and production;
- conflict resolution too - it only escalates issues to the Board when judged appropriate;
- all this in collaboration with the Mageia Board (whose president is de facto president of the Council too).
It will likely be up to 15 people this year. That's a lot, yes. We have very high expectations on the way people will interact. And we hope this Council to be a good leader for the project.
The Mageia Community Council is elected by Mageia Teams members from their peers. Every year, each team will name/elect three of their active peers for three roles, respectively:
- representative to the Council,
- team leader,
- team deputy leader.
These should be named because they:
- have shown to be reliable in their team' activity and in the course of the project;
- would be good leaders;
- are balanced and relaxed people;
- are careful listeners;
- are attentive to details, both in technology and in discussions;
- have a strong understanding of Free Software;
- are true believers and advocates of what makes Mageia a place apart.
The Council will hold an official public online progress meeting every two weeks on #mageia-council on Freenode IRC network; same for the board, only Council members and special attendees can speak. Meeting notes will published on the wiki.
It will have a publicly archived mailing-list (mageia-council); they would also have a private mailing-list for matters that would require public discretion. Both are archived and here again, only the Council members will subscribed to these lists.
(see teams to be completed)
Mageia Teams are set per area of primary expertise (packaging, OS tools development, translation, etc. see below for the existing full list).
They are responsible for:
- their own coordination and production;
- acknowledging Council decisions and coordination;
- providing feedback to their representative for the Council;
- documenting their work (regular meetings, notes, howtos, etc.);
- their own sponsoring/mentoring program, in order to welcome and train newcomers;
- advocating their role within and outside the Mageia project;
- if appropriate, experimenting and providing new ideas (within their team or with other teams).
They are constituted by active people in the project community that have been recognized & sponsored by their peers into the team.
You can not elect or be elected as a leader or a representative to the Council if you are not officialy part of a team, that is, if you have not been sponsored and mentored into it before.:
- Packaging team (integrating & packaging software; about 80 people enlisted already)
- Security team (part of the packaging team)
- Developers team (distribution specific tools development; 39)
- Documentation team (35)
- Translation team (translating software, website; 98 people)
- QA team (37)
- Triage team (11)
- Users' communities management and representation team (forum/mailing-lists/IRC moderators and admins (about 100 people with current locales); this one is pretty big so it may need to be organized into three dedicated groups)
- Web team (building, maintaining Web sites & apps; 26)
- Designers (11)
- Marketing team (10)
- Communication team (28)
All these teams are defined after their main activity and skills-area. Still, they all have common concerns; so one big challenge will be to find a way to make them collaborate and work on common sub-projects, by pair at least.
Every team will have its public communication channel(s); what is critical is to have at least three things:
- a dedicated input channel (a public, properly indexed Web page; can be a blog, a mail contact, a dedicated forum...);
- a public archive of activity/discussions (for instance, a mailing-list archive);
- a public regular summary, archived and pushed to the Council.
Most, at least several, teams will opt for a mailing-list. It may not suit everyone. Some may want to use a forum, some project management tool or other, specific tools. We will wait for each team to discuss on their own (or we can setup a mailing-list for each already) and propose/ask what tools they would use (we already have discussions about Bugzilla, build system, etc. but what each team needs is not obvious to everyone). PLEASE do so on your team's wiki page first and warn for it in a separate thread.
What will be at least enforced are the Council and Board communication channels (IRC & mailing-lists).
There are two possibilities for how teams could be formed.
We can first design what we want, what we need and define teams from that end; so we know who is in charge of what piece in the project.
Or, we can design teams for directions & places where we want to go/improve. And apart from their regular work for the distribution roadmap, let those teams come up with concepts, ideas, projects on their own (and doing cross-teams work) and present them at the Council & Board; let them decide openly for each if it fits in the current project release cycle and timing or not at all. And manage how to stop, improve, focus or integrate these pieces into the project.
Goal is not to digress from the very necessary job that will be prioritized, but to allow us to go further than what each team would have done if tasks were assigned from the top management only.
Shall we manage to make this organization work in the coming year or so, we may extend the number of teams in other areas, precisely to open new fields to the Mageia project and Linux distribution.