Project:Council/Metastructure reform 2005/Alternative

This document is an RFC on a complete organization structure for Gentoo, based upon the FOSDEM reform proposal and subsequent discussions.

Scope of this document
This document is a proposition for a new metastructure organization model, based on the past metastructure, the FOSDEM reform proposal and subsequent discussions, and taking into account the way we currently work. The past discussions were not sufficiently precise to raise lots of objections. The objective of this document is to describe precisely a specific option, hopefully helping people to make their mind about it and raise constructive remarks on the points they disagree with.

The need for reform
The following problems have been identified with the current metastructure organization model:


 * A growing number of developers doesn't fit in the current TLP/projects layout (especially package maintainers and new projects like Enterprise), requiring a reorganization of the TLP/projects layout.
 * The Managers meeting, which is the only current decision-making entity, is a centralized, non-representative, non-scalable and static system which doesn't fill efficiently its role anymore today.
 * With more developers and projects and the decline of the managers meetings role, Gentoo has shifted toward a decentralized model centered around projects rather than TLPs, and the metastructure must evolve to match that fact.
 * The current metastructure doesn't help identifying dead developers, leads or projects and has no mechanism to proactively solve these issues (we discover dead things when we need them)
 * A new metastructure model should facilitate project-external communication, dispute resolution and definition and realisation of global goals which are the current challenges to our ever-growing organization.

Principles of this proposal
This new metastructure model tries to solve these perceived problems and reach the following objectives:


 * Ensure that all developers and all Gentoo development areas belong to official projects in the new structure
 * Define rights and duties for every official position in the structure
 * Shift from a TLP-centered model to a Project-centered model and set rules to avoid its drawbacks (lack of inter-project communication and bad dispute resolution system)
 * Limit the changes necessary to go from the current structure to new model

Projects
At the center of the new organization model is the concept of. Projects are work units dedicated to one precise subject in Gentoo, regrouping developers working on that subject. Developers are encouraged to belong to several separate projects, reflecting their areas of interest. All Gentoo development activities must be represented in the project structure and projects can be created or removed to match current activities with the current project metastructure.

Each project maintains an up-to-date project page, especially the developer team roster reflecting its active developers. A developer is considered inactive if he doesn't appear in any project team active roster, and his developer privileges will then be retired.

Project leads
At the head of each project there is one (and only one) Project lead. Other titles (head strategic monkey-general, operational subproject co-manager...) can be assigned inside a project but there should be only one official lead. The project lead role replaces the current Operational Lead role.

A project lead is responsible for keeping the project running, organize project meetings, communicate externally on the project's actions, and keeping his project page and developer roster up to date. They represent their project developers in other meetings and is the main media for project members to transmit concerns about other projects actions.

Project leads are designated through the (current) meritocracy system (old lead designates new lead) inside each project. Elections can be organized inside a project if the current lead prefers to designate their successor this way. Disputes between project members and project leads that can't be solved in project meetings should be brought up to the Group secretary.

Project groups
Based on their objectives, Projects are grouped into categories called. The purpose of these project groups is to define a layer at which decisions affecting projects from the same group can be discussed and resolved, without affecting all the other projects.

Group secretaries
Each project group has a group. The secretary is responsible for organizing group councils and resolve disputes between projects of the group and between project members and project leads. He ensures that the leads of the projects inside his group fulfill their obligations regarding project meeting organization, external communication and developer roster. He represents the position of the projects inside his group in Secretaries councils.

The secretary role is a diplomatic role that requires both intimate knowledge of the projects inside his group and good communication skills. They should be representative of the developers in their group and be as impartial as possible in dispute resolution. They should be elected by group developers. Eligible candidates should be Gentoo developers for at least a year, and should not already be a project lead. The best runner-up is elected substitute secretary and can be called to temporarily fill the secretary role in times of need.

Scope of decision
This metastructure model introduces a decentralized decision-making process, acknowledging the way Gentoo is currently working. Decisions should therefore be categorized based upon the impact they have.

decisions are those affecting only one project. The creation of a subproject or a specific herd are examples of these. Those proposals can be discussed on gentoo-dev but do not need a GLEP. If there is no consensus, they are discussed and decided on project meetings, so they must be announced in the meeting agenda and the decision must appear in posted meeting minutes. The project lead is reponsible for the decision implementation.

decisions are those affecting a specific area of Gentoo development, while remaining in the same project group. The creation of a new category in portage or a new global USE flag, for example, are solved at Tree group level. Those proposals must be discussed on gentoo-dev and can be described in a GLEP. If there is no consensus, they are discussed at each project level and then discussed and decided on group councils. When a decision is taken, the group secretary should check that it was correctly implemented, for example by having a systematic "old decisions status" item at the next group council.

decisions are those affecting multiple areas of Gentoo development, or projects located in separate groups. Those proposals must be discussed on gentoo-dev and must be described in a GLEP. If there is no consensus, they are discussed at each project and group level, and then discussed and decided on secretaries councils. When decided, the MetaBug taskforce project has the task to keep the ball rolling on the implementation and ensures it goes to completion.

Project meeting
Project meetings should be held at least once every two months. Members of those meetings are the official project developers and their lead. An official agenda should be posted to gentoo-dev so that developers interested in the discussion can join the meeting. Meetings should be public. The official agenda is discussed by the project developers, then an open-floor discussion, open to everyone, can take place. The project lead has the final say on decisions in project-level decisions made at project meetings.

After the official agenda is posted, if another project thinks the decision to-be-taken will impact them directly, their project lead should ask that this decision should be resolved as a Group-level or Global-level decision. The agenda should clearly identify points that may affect other projects so that those other projects know about it easily.

Project leads are responsible for organizing timely meetings, gather and post agenda questions and publish meeting minutes. They can invite developers from other projects to discuss and resolve efficiently the agenda points. In case of absence, project leads must appoint a substitute that will take their responsability. If project leads can't steadily fulfill their obligations, they should step down and designate a new project lead. Disputes on this subject between project members and the lead should be brought to the group secretary.

Group council
Group councils should be held whenever a group-level decision has to be taken or to the request of a project lead or group secretary, as often as necessary. The members of the group council are the leads of each project in the group (or their substitute) and the group secretary. An official agenda must be posted to gentoo-dev prior to the council. The council is public. The official agenda is discussed by the council members, then an open-floor discussion, open to every developer, can take place. If required, decisions can be resolved using one member = one vote system.

After the official agenda is posted, if a project in another group thinks the decision to-be-taken will impact directly them, their project lead should ask that this decision should be resolved as a Global-level decision.

Group secretaries are responsible for organizing councils, gather and post agenda questions and publish council minutes. They can invite developers from other projects to discuss and resolve efficiently the agenda points. If the secretary cannot temporarily fulfill its role, he can be replaced by the elected substitute secretary. If group secretaries can't repeatedly fulfill their obligations, they should resign and call for new elections. Elections are then organized by the substitute secretary. Disputes on this subject or on the impartiality of a secretary should be brought to the secretaries council.

Secretaries council
Secretary councils should be held whenever a global-level decision has to be taken or to the request of a group secretary, as often as necessary. The members of the secretaries council are the secretaries of each group. An official agenda must be posted to gentoo-dev prior to the council. The council is developer-only. The official agenda is discussed by the council members, then an open-floor discussion, open to every project lead, can take place. If required, decisions can be resolved using one member = one vote system.

Group secretaries should elect amongst them a Secretariat project lead that is responsible for organizing councils, gather and post agenda questions and publish council minutes. Group secretaries are encouraged to invite project leads or specific developers to discuss and resolve efficiently agenda points.

Services group
This project group is meant to contain all projects which offer services to both developers and users. It includes the following projects:

Tree group
This project group is meant to contain all projects which handle the packages present in the portage tree. It includes the following projects:

Profiles group
This project group is meant to contain all projects which maintain Gentoo profiles and ensure that packages work on specific systems, including architecture teams and specialized profiles like hardened and embedded. It includes the following projects:

Taskforces group
Some groups work to produce Gentoo-branded releases, some others work horizontally to coordinate work on specific bugs. We call them the Taskforces, and this project group regroups them. It includes the following projects:

Communication group
This project group is meant to contain all projects that ease communication within Gentoo, from Gentoo developers to Gentoo users, and all external communication. It includes the following projects:

The contents of this document are licensed under the license.