Project:Council/Metastructure reform 2005/FOSDEM
This proposal was initially drafted at the FOSDEM Gentoo Developer Meeting in Brussels on 27 February 2005, refined, discussed and edited in the week following the event among the participants listed above.
Introduction
Scope of this document
At FOSDEM's Gentoo Developer Meeting held on Sunday, 27 February 2005 in Brussels, a group of 23 Gentoo developers discussed the current state as well as means to improve Gentoo. This draft identifies problems in the current situation, describes ways to solve them, and presents a plan for the implementation of the proposed changes.
Motivation
Some of the more vocal developers have expressed their unease with the current state of things Gentoo on many occasions. Some of the perceived inadequacies have to do with size: development and resources used to be taken care of by just a handful of people who'd get the job done without much ado. At today's number of developers, however, the diversity of needs and ambitions has made it impossible to sustain the old level of implicit understanding over the ways the project is managed.
The Brussels meeting has tried to go a step further than just expressing unrest: we try to put the finger on those problems which the entire group agreed were crucial to get out of the way, for a better understanding of present tasks and future challenges.
Two things dominated the discussion in Brussels: the need for better representation of developers who are currently not entirely happy with the way they're being integrated into the process, and our wish to pave the way for future growth of the Gentoo project. Everybody who couldn't attend the meeting should take this proposal as a starting point for discussion, not a ready solution. The document has plenty of room for comments and additions, but should be understood as an attempt at triggering a debate among all Gentoo developers on all levels.
Assessment of the current structure
There are no global goals
The lack of strict definitions for managing and centralising our implementation of strategic goals, and the absence of clear visibility and transparency to the public weaken the Gentoo effort. Individual projects have defined their goals for 2005, but there's no equivalent roadmap for Gentoo as a whole. What we miss most in Gentoo development at present are communication and coordination between separate projects.
We used to have global goals defined by a head architect, managed and enforced by release engineering as release goals and visible on the releng page . Currently it's nobody's job to define them. The GLEP process seems to have replaced it. However, nobody feels responsible for managing or enforcing the GLEPs, and their realisation is inherently intransparent and invisible to not only the users but also most of the developers, to the community as a whole. This causes the impression of stagnation among a majority of developers and is an obstacle to the development process itself.
The current metastructure is imbalanced
Currently, the Gentoo metastructure does not adequately reflect the realities of development. Architecture teams and package maintainers, despite forming the bulk of the developers, are underrepresented, while key persons who used to shoulder much of the workload have become less active. There are top level projects which inherited their status as a TLP for purely historical reasons. The current structure was intended to provide a framework in which much of the old informal spirit could be kept alive. It has worked well, in that respect and others, but is perceived today by many as unable to cope with change, to accommodate the much larger scale of Gentoo development, and to provide the level of support necessary for active development inside the greater Gentoo realm.
The manager meetings have grown pointless
Recently, there has been a higher level of attendance to manager meetings by non-managing developers than actual top level project leads. At the same time, many developers have voiced that they see themselves more and more kept at distance by the managers. Worst of all, at most of the recent manager meetings even agenda items could not be discussed, let alone voted on, because there just were not enough managers present.
Proposed Solutions
Defining the Gentoo roadmap
To enhance communication among the different projects, it is necessary to make them all heard, understood and recognised. An important element for better communication is the designated "Taskforces" projects group described below. This year's "2005 Project Goals" that have been published on the mailing lists and in the GWN in January are first steps in the right direction. We propose that those individual expressions of ambitions of each projects will be formalised with mandatory project reports, consisting of finished tasks as well as current work and future goals, on a regular (e.g. quarterly) basis. On top of this, we think public meetings (as some projects are already holding regularly) will greatly add to the transparency needed when trying to build a fair view of all aspects of Gentoo development. Finally, a summary of all project reports will be collated to a global Gentoo roadmap document to be published and updated at the website.
Complete overhaul of the Gentoo metastructure
We propose to create a new global project structure. Projects in this new structure would be placed into one of the following seven "project groups":
- Services
- Tree
- Profiles
- Tools
- Taskforces
- Production
- Communication
Each group should have a coordinator which should not fullfill the function of a lead developer, instead they should help the projects' lead developers to work together.
To avoid any misinterpretations of our views, especially with regard to how important or unimportant individual projects might be, the following lists are all just ordered alphabetically, and are separated only between existing projects and those to be created in the new structure.
Services
This project group is meant to contain all projects which offer services to both developers and users. The following current projects should be contained:
- Developer relations
- GLEP Coordinator
- Infrastructure
- Ombudsman
In addition to these existing projects, a new team needs to be created to fulfill the role of making sure manager meetings that have been scheduled are being attended by a representative of each group, of writing and distributing meeting minutes, collecting project reports and other typical office management functions:
- Secretariat
Tree
This group contains all projects that directly work on the Portage tree. As we all know that the tree is easily breakable, all these projects should be kept together in one group. All discussions about splitting or creating Portage categories and matching herds are to be decided within the Tree and moderated by its coordinator, thus avoiding interference with other groups. Members of the Tree group are:
- Base system
- Desktop (including i18n and desktop-based network clients)
- Development (including languages, vim and emacs)
- Kernel
- Networking (including mobile computing)
- Server
- System utilities
Herds (and solitary package maintainers) will be distributed among those projects according to this table. Herds that are spanning more than one project are marked in italic:
| Base system | base-system pam toolchain |
|---|---|
| Desktop | accessibility cjk commonbox desktop-dock desktop-misc desktop-wm fonts games gnome-accessibility gnome gnustep graphics gstreamer kde-core kde-other kde-themes media-optical media-tv middle-east mozilla openoffice pda sci sound video vmware wine x11 xemacs xfce net-im net-irc net-mail net-misc net-news net-p2p net-www printing |
| Development | ada common-lisp dev-tools java haskell lang-misc lisp ml perl php prolog python qt ruby scheme wxwindows tcltk emacs vim dotnet |
| Kernel | kernel alpha-kernel hppa-kernel mips-kernel ppc-kernel sparc-kernel x86-kernel |
| Networking | net-dialup net-fs net-misc voip comm-fax netmon secure-tunneling mobile |
| Server | apache cluster mysql-bugs postgresql sysadmin web-apps www-proxy www-servers net-im net-irc net-mail net-misc net-news net-www net-zope |
| System utilities | benchmarks cron crypto forensics shell-tools tools-portage antivirus app-doc app-text text-markup app-dicts |
Profiles
This entirely new group contains all teams that create and support profiles. This means that all architecture projects will be eligible for direct representation if they are officially supported profiles, regardless of hardware platform, operating system or other characteristics. Examples are:
- amd64
- Gentoo/Mac OS X
- PPC
- PPC64
- sparc
- x86
- ...
and many others. Additionally the projects:
- Alternative architectures
- Embedded
- Hardened
will belong to the Profiles group, too. This project group is more volatile in nature than others, it is bound to be subject to frequent change, e.g. whenever subprojects of Alternative architectures ascend to project status of their own, or profiles are dropped or merged.
Tools
Common group of all application projects that are hosted by Gentoo.
- Portage
- Catalyst/Genkernel project
- Other tools (eclectic/Keychain/Tenshi)
Taskforces
Bugs don't stop at project borders. To coordinate work on these kinds of bugs, we need a project group of taskforces that consist of developers of different projects. Best example for this is probably the security team that has close contacts to all profile teams. We considered the following projects to be member of the Taskforces project group:
- Quality assurance
- Security
A new team that has already been discussed briefly at a recent manager meeting under the name "Bug Squad" is the proposed Metabug project, a taskforce that would ensure that bugs needing interaction on lots of different teams will get solved in a timely manner. Because of lack of communication between current teams, those bugs are currently left unresolved.
- Metabug
Production
For all production-related projects this project group should be created. Natural candidates are:
- Release engineering
- Enterprise
Communication
All those projects that ease communication within Gentoo, from Gentoo developers to Gentoo users, and all external communication should be restructured in a project group containing three existing projects:
- Documentation
- Events
- Forums
- PR and press relations
In addition to these, two new projects will provide a focal point for artistic design work (from CD covers to presentation templates) and everything pertaining to marketable aspects of Gentoo.
- Artwork
- Sponsoring, merchandising and vendor relations
New structure for representative meetings
One of the most important changes to what is currently called the managers' meeting will be a much broader base of people eligible for participating in the decision-making process. The tasks of inviting to meetings, distributing the agenda and the minutes after the meeting, and most importantly confirming who is going to participate for each project group will be the secretariat's role.
Each of the projects defined above should have one representative. This can be one of the lead developers, or all leads in rotation, or any member of the group appointed by their peers. As they will be acting independently during meetings, this is a position of trust that can be gained and lost, and members of the projects should elect the representatives for their groups - and be able to replace them when needed. Additionally, we think that no developer should be a representative for more than two projects at the same time, as this contradicts the aim of diversified projects and project groups.
This structure eases the process of decision greatly. If a problem only affects projects of the same group, they will surely find a solution among themselves. Only if problems are spread across several project groups, those affected should confer and find a solution in consensus. Moreover, the new ability to rotate representatives for each project provides more flexibility: If an item on the agenda requires in-depth knowledge or the presence of the developer responsible for a particular project, appointments can be handled accordingly for this role before each meeting. Most importantly, if roles can be appointed freely by each project, there will be no need for cancellation of scheduled meetings, and fears of misrepresentation will also become unnecessary: shifting the assignment to someone both available at that date and known to act responsibly should be feasible for every project.
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Jose Alberto Suarez Lopez, Benjamin Judas, Patrick Lauer, Marcus D. Hanwell, Fernando J. Pereda, Marinus Schraal, Michael Hanselmann, Christian Hartmann, Sune Kloppenborg Jepsen, Karl Trygve Kalleberg, Mike Doty, Thierry Carrez, Danny van Dyk, Jan Brinkmann, Luca Barbato, Ulrich Plate, Pieter Van den Abeele, Lars Weiler, Markus Nigbur, Jochen Maes, Stefan Knoblich, Michael Imhof, Torsten Veller, Marc Hildebrand
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 content of this document is licensed under the CC-BY-SA-2.0 license.