Project:ComRel/Developer Handbook/Developer hierarchy
Introduction
This section aims to explain the Gentoo development hierarchy and gives developers an insight to how Gentoo Linux development management is structured.
A short history of Gentoo's management structure
The first attempt to come up with a management structure to solve problems with coordination and communication issues was made in 2003 with the structure described in GLEP 4. As Gentoo grew larger over the time, some problems with the management structure were discovered and a new one was needed to solve these issues. GLEP 39 describes both the reasons behind this as well as the outcome of the discussion.
Current management structure according to GLEP 39
A project is a group of developers working towards a goal (or a set of goals):
- A project exists if it has a web page at
https://wiki.gentoo.org/wiki/Project:${PROJECT_NAME}that is maintained. ("Maintained" means that the information on the page is factually correct and not out-of-date.) If the webpage isn't maintained, it is presumed dead. - It may have one or many leads, and the leads are selected by the members of the project. This selection must occur at least once every 12 months and may occur at any time.
- It may have zero or more sub-projects. Sub-projects are just projects that provide some additional structure, and their web pages are in the project's space.
- Not everything (or everyone) needs a project.
- Projects need not be long-term.
- Projects may well conflict with other projects. That's okay.
- Any dev may create a new project just by creating a new page (or, more realistically, directory and page) on the wiki at Developer Central Project pages and announcing it on the gentoo-dev mailing list per the instructions in GLEP 39[1].
Global issues will be decided by an elected Gentoo council:
- There will be a set number of council members. (For the first election that number was set to 7 by acclamation.)
- Council members will be chosen by a general election of all devs once per year.
- The council must hold an open meeting at least once per month.
- Council decisions are by majority vote of those who show up (or their proxies).
- If a council member (or their appointed proxy) fails to show up for two consecutive meetings, they are marked as a slacker.
- If a council member who has been marked a slacker misses any further meeting (or their appointed proxy doesn't show up), they lose their position and a new election is held to replace that person. The newly elected council member gets a 'reduced' term so that the yearly elections still elect a full group.
- Council members who have previously been booted for excessive slacking may stand for future elections, including the election for their replacement. They should, however, justify their reasons for slacking and should expect to have it pointed out if they don't do so themselves.
- The 'slacker' marker is reset when a member is elected.
- If any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point.
- Disciplinary actions may be appealed to the council.
- A proxy must not be an existing council member, and any single person may not be a proxy for more than one council member at any given meeting.
Consequences of Gentoo's management structure
As a consequence of the new management structure, global decisions will be made by the elected council. This should give Gentoo a general direction - smaller issues affecting only a project or two should be decided inside the projects involved, probably with input from other developers. The council should be a fair representation of the developer base as every developer is able to vote, so interests should be represented in a fair way. If the council does a bad job and the developer base is unhappy with its work, the council can be voted out.
Decisions within a project can be made by the people inside the project itself, of course coordination between the projects is necessary. The (sub-)project leads are usually responsible for doing this.
Most projects have an Operational and Strategic lead, but basically it is up to the project what positions are created and how they are called - this also applies to sub-projects.
Some projects appoint a contact person for communication to another project e.g. a developer within the forums project who is responsible for communication with the infrastracture project.
All in all, the current structure has no clear list of responsibilities the project leads are supposed to satisfy. They are chosen by the members of the project, the practical responsibility of a lead is "whatever the members require", and if that isn't satisfied, the members can get a new lead (if they can find somebody to take the job!).
References
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Seemant Kulleen, Shyam Mani, Karl Trygve Kalleberg, Mike Frysinger, Alastair Tse, Paul De Vrieze, Nicholas D. Wolfwood, Marius Mauch, Daniel Black, Wernfried Haas, Chrissy Fullam, Łukasz Damentko, Daniel Robbins, Markos Chandras, John P. Davis, Tim Yamin, Jorge Paulo, Zack Gilburd, Benny Chuang, Erwin, Jon Portnoy, Carl Anderson, Donny Davies, Peter Gavin, Dan Armak, Owen Stampflee, and Ciaran McCreesh on December 7, 2013
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.