[ << ] [ < ] [ Home ] [ > ] [ >> ]

5. Developer hierarchy

• Introduction
• A short history of Gentoo's management structure
• Current Management structure according to GLEP 39
• Consequences of Gentoo's management structure

5.a. Introduction

This section aims to explain the Gentoo development hierarchy and gives developers an insight to how Gentoo Linux development management is structured.

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

5.c. 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 www.gentoo.org/proj/en/<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) in gentoo/xml/htdocs/proj/en and announcing it on the gentoo-dev-announce mailing list.

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.

5.d. 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!).

[ << ] [ < ] [ Home ] [ > ] [ >> ]

The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.