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.
Introduction
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
Organization
Projects
At the center of the new organization model is the concept of Projects. 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.
Co-leading could be an option, as it is the way some projects work, for example the Portage team (3 leads) or the Documentation team (2 leads).
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 Project Groups. 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 Secretary. 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.
Decision-making process
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.
Project-level 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.
Group-level 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.
Global-level 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.
All meeting agendas should use a specific subject line so that they can easily be filtered, to make sure everyone gets them properly.
Proposed groups and projects
Services group
This project group is meant to contain all projects which offer services to both developers and users. It includes the following projects:
| Project | Definition | Current corresponding entity (and lead) |
|---|---|---|
| Infrastructure | This project provides the resources, services and technology necessary to support the Gentoo Linux projects. It is responsible for the security, availability and integrity of the data stored on the Gentoo Linux servers. | Infrastructure TLD (Ramereth) |
| Devrel | This project handles many personnel-related tasks, such as adding and removing developers, solving conflicts, and providing a contact point for prospective and current developers. | Devrel TLD, minus managermeetings, ombudsman and user-relations (avenj) |
| Secretariat | This project handles metastructure-related tasks, like organizing secretaries councils, keeping the project list up-to-date, administrate the GLEP list, providing an ombudsman service to handle issues that the metastructure can't solve efficiently. Its lead is chosen amongst group secretaries. | Metastructure TLD + Ombudsman, Managermeeting (pauldv,g2boojum?) |
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:
This can obviously be split in another way. Feel free to propose alternative Tree splitups.
Another option is to split the Tree project group into two project groups, one "Base" containing the Portage, Base system, Desktop Base and Kernel on one side, and one "Applications" with the other projects.
| Project | Definition | Current corresponding entity (and lead) |
|---|---|---|
| Portage | This project works to provide a continuously expanding and developing tool for the management and installation of packages. The developers work on providing a coherent system that is as trouble free as possible (backwards compatible, automated, and simple). | Portage TLD (genone/jstubbs/ferringb) |
| Base system | This project maintains, develops and improves Gentoo system packages, providing a consistency in compilers, toolchains, filesystem layouts and startup scripts across all the architectures which Gentoo Linux supports. It maintains the following herds: base-system, pam, toolchain. | Base TLD, minus the subprojects (vapier,azarah?) |
| Kernel | This project maintains the kernel sources officially available through the Portage tree. It combines and tests several kernel patches to provide the official patchsets, and ensures optimal Gentoo support for functions like bootsplash or udev. It maintains the following herds: kernel alpha-kernel hppa-kernel mips-kernel ppc-kernel sparc-kernel x86-kernel. | Kernel TLD (johnm) |
| Desktop base | This project maintains the base packages underlying the desktop experience, including X, desktop environments, i18n and accessibility. It maintains the following herds: accessibility cjk commonbox desktop-dock desktop-misc desktop-wm fonts gnome-accessibility gnome gnustep gstreamer kde-core kde-other kde-themes middle-east x11 xemacs xfce | Main part of the desktop TLD (spyderous) |
| Desktop applications | This project maintains the applications related to the various domains accessible through a Gentoo Linux Desktop or Workstation, including gaming, science, office or multimedia capabilities. It aims to improve Gentoo's relevance as a specialized environment. It maintains the following herds: games graphics media-optical media-tv openoffice pda sci sound video vmware wine | Part of the desktop TLD + new subprojects (?) |
| Networking | This project maintains the various network client applications and network monitoring tools. It maintains the following herds: mozilla net-dialup net-fs net-misc voip comm-fax netmon secure-tunneling mobile net-p2p (and the client part of net-im net-irc net-mail net-misc net-news net-www) | New project (?) |
| Server | This project maintains the various server applications. It aims to develop and improve Gentoo's relevance as a reliable server platform. It maintains the following herds: apache cluster mysql-bugs postgresql sysadmin web-apps www-proxy www-servers net-zope (and the server part of net-im net-irc net-mail net-misc net-news net-www and printing) | New project (?) |
| Development | This project maintains the development-related applications, including the various languages and libraries available in the Portage tree. It maintains the following herds: ada common-lisp dev-tools java haskell lang-misc lisp ml perl php prolog python qt ruby scheme wxwindows tcltk dotnet | New project (?) |
| Other (sexier name wanted) | This project maintains the common tools that are not part of the base system and don't fit specifically in another project, including text editors and processors or shells. It maintains the following herds: emacs xemacs vim benchmarks cron crypto forensics shell-tools tools-portage antivirus app-doc app-text text-markup app-dicts (and the client part of printing) | New project (?) |
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:
Not sure x86 needs a specific project, please tell me how you see it.
| Project | Definition | Current corresponding entity (and lead) |
|---|---|---|
| x86 | This project provides the x86 profiles and are responsible for the x86 portage keywords. | New project (seemant,Tester?) |
| amd64 | This project provides the amd64 profiles and are responsible for the amd64 portage keywords. | amd64 subproject (kingtaco?) |
| ppc | This project provides the ppc profiles and are responsible for the ppc portage keywords. | ppc subproject (pylon?) |
| sparc | This project provides the sparc profiles and are responsible for the sparc portage keywords. | sparc subproject (gustavoz?) |
| alpha | This project provides the alpha profiles and are responsible for the alpha portage keywords. | alpha subproject (agriffis?) |
| ppc64 | This project provides the ppc64 profiles and are responsible for the ppc64 portage keywords. | ppc64 subproject (?) |
| Misc architectures | This project regroups Gentoo Linux architectures on uncommon hardware that are not officially supported (for example in GLSAs). This includes the mips, arm, hppa, ia64 and s390 profiles and portage keywords. | mips, hppa subprojects (?) |
| embedded | This project provides the embedded and arm profiles, ensures that packages are compatible with an embedded-oriented toolchain and provides the tools improving the Gentoo-based embedded development. | embedded subproject (pebenito,vapier?) |
| hardened | This project provides the hardened profiles, ensures that packages are compatible with an hardened-oriented toolchain, and provides the tools improving the Gentoo-based hardened systems support. | Hardened TLD (method) |
| Alternative platforms | This project manages efforts to support alternate Gentoo platforms and runtime environments, including MacOSX and BSD. | gentoo-alt TLD (pvdabeel) |
Taskforces group
This group could be splitted between "Production" and "Taskforces" project groups.
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:
| Project | Definition | Current corresponding entity (and lead) |
|---|---|---|
| Release Engineering | This project focuses on coordinating and improving the creation of official releases of Gentoo Linux, including maintaining the Catalyst and Genkernel tools. | Releng TLD (wolf31o2) |
| Enterprise Gentoo | This project prepares the future release of Enterprise-oriented Gentoo platform. | New project (?) |
| Security | This project ensures that vulnerabilities in software accessible through Gentoo Linux Portage tree are found and fixed in a timely manner, so that our users remain protected against known vulnerabilities. | Security TLD (koon) |
| QA | This project takes care of horizontal efforts to keep the tree actively maintained, global quality of ebuilds, pertinence of keywords, abandonware cleanup. It also maintains lists of specialized field experts so that developers can get help on tricky subjects. | QA TLD (?) |
| MetaBug | This project takes care of bugs needing interaction from a lot of different teams and of global goals. It ensures those are solved in a timely manner. | New project (?) |
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 Partnerships project might be better as a subproject of PR.
| Project | Definition | Current corresponding entity (and lead) |
|---|---|---|
| Documentation | This project is responsible for the creation and maintenance of all official Gentoo documentation. It is committed to providing clear, concise, and original documentation. | Documentation TLD (neysx) |
| PR | This project is responsible for public relations, in particular institutional communication and press relations. It defines the website contents, official artwork and models. | PR TLD, minus events, gwn and presentation subprojects (klieber) |
| User relations | This project is responsible for user to developer communication and maintains our user-supported resources like the Forums. | Userrelations, GWN subprojects (plate?) |
| Events | This project keeps track and helps organizing various Gentoo-related events. It maintains typical Gentoo presentations. | Events, presentation subprojects (stuart) |
| Partnerships | This project takes care of sponsoring research, merchandising and other vendor relations. | New project (?) |
Some projects like "Enterprise Gentoo", "Partnerships" or "MetaBug", might not be created if they lack the ressources... Consider that they are on the wishlist :)
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Thierry Carrez
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.
The contents of this document are licensed under the CC-BY-SA-1.0 license.