Gentoo Top-Level Management Structure

1.  Gentoo top-level management structure

What was the purpose of the new management structure?

The purpose of the new management structure was to solve chronic management, coordination and communication issues in the Gentoo project. In particular, we had no clearly defined top-level management structure, and no official, regular meetings to communicate status updates between developers serving in critical roles. In general, most communication took place on irc and irregularly via email. There was also little to no accountability, even at a high level, to complete projects on time.

Because of this prior state of affairs, it was difficult to set goals and track the status of projects. This lack of communication and coordination also made it difficult for top-level developers to manage their own projects. In addition, we had other chronic problem of not having clearly-defined roles and scopes of executive decision-making authority for top-level developers, which resulted in many top-level developers doubting that they even have the authority to manage their own projects and sub-projects. While this had *never* been the intention of top-level developers, it is the unfortunate result of an unstructured development process: no one knew what was going on, and everyone deferred to the Chief Architect for all executive decisions.

Clearly, a plan was needed to swiftly and permanently address these issues by increasing communication, coordination, and accountability. Roles and scopes of executive decision-making authority needed to be defined for top developers so that they have a clear mandate as well as accountability to manage their projects and thus ensure their projects completed their appointed work efficiently and on-schedule.

Initial implementation

Initial implementation of the new management structure began by creating official top-level management structure. This management structure consists of the Chief Architect and a group of developers that will be given the title of Top-level Managers. Top-level Managers will be accountable for the projects they manage, and be responsible for communicating the status of their projects to the rest of the Top-level Managers and Chief Architect, as well as other responsibilities detailed later in this document.

All the top-level projects in the Gentoo project are in the process of being clearly defined, including goals, sub-projects, members, roadmap and schedules. The "Hardened Gentoo" page at http://www.gentoo.org/proj/en/hardened/ is an excellent example of such a top-level project definition, and many other top-level projects currently exist today.

Certain executive decision-making authority will be granted to these projects, as agreed upon by the Chief Architect, Top-level Managers and project members. Then, as part of the initial implementation of the new management structure, a Top-level Manager or managers will be officially adopt projects and ebuild herds. These managers will be responsible for tracking the status of the project, ensuring that the project meets targets and is generally managed properly. Manager responsibilities are described in detail later in this document.

Management team

The current top-level management team is as follows (in no particular order):

• Seemant Kulleen (seemant)
• Jay Pfeifer (pfeifer)
• Joshua Brindle (method)
• Kurt Lieber (klieber)
• Pieter Van den Abeele (pvdabeel)
• Jon Portnoy (avenj)
• Paul de Vrieze (pauldv)
• Sven Vermeulen (swift)

Management charter

1) Constructive, professional communication: All communication should be focused on improving the management of Gentoo projects, should be constructive in nature and should be shared in a friendly, professional manner.

2) Accountability to peers: Allow fellow members of this list to hold us accountable to follow-through on projects and meet deadlines. Keep fellow members accountable.

3) Management of projects: empower managers to have the authority and strategic direction necessary to properly manage thier projects and efforts to ensure projects complete their appointed work on time.

4) Results: our expectation is that our efforts, when properly executed, will result in the Gentoo project's ability to meet deadlines, have much better communication and coordination throughout the entire project, higher overall quality and a more positive experience for all.

Manager responsibilities

Every top-level Gentoo project will have a clearly defined scope, and clearly defined and explicit executive decision-making authority that will be granted to managers of the project to exercise and/or delegate as they see fit. Both the scope and any necessary decision-making authority must be agreed upon by both the Chief Architect and project members. The scope and executive authority of a project can be expanded over time as required as approved by the Top-level Managers and Chief Architect.

In addition to decision-making authority, managers have the following responsibilities:

1. Keep a complete list of all projects and efforts you are managing, and associated gentoo.org project page up-to-date
2. Manage and track the status of these efforts. This includes active direction as well as passive tracking of progress.
3. Define clear goals, roadmaps and timelines (preliminary if necessary) for every effort.
4. Proactively identify efforts that have problems and need help.
5. Ensure that your efforts are completed on-time, or that any efforts that are behind-schedule are reported in a timely manner.
6. Remain focused. Make sure that you are not managing more than you can handle.
7. Fulfill formal communication and coordination responsibilities required by top-level managers (weekly meetings, etc.)
8. Fulfill formal communication and coordination responsibilities required by individual efforts (project meetings, communication with project members, etc.) This is important as our management of projects means that we have the responsibility not only to communicate with our peers but also those who we are managing. This communication should be frequent, have a formal component (planned meetings, official status updates, etc.) and model good management practices to members of our teams.
9. RECURSIVE FUNCTIONALITY: At an appropriate time, implement these management practices for *sub*-projects (define managers, clear sub-project goals, grant executive authority) with you serving as primary authority.

Meetings, logs and status updates

Currently, weekly manager meetings are held on irc, and all Gentoo developers are welcome to join the meeting channel and view the meeting in progress. In addition, after the meeting completes, the floor is opened for questions and comments by developers. The weekly meetings generally take place on Monday. After the meeting and open-floor session is concluded, a log of the meeting is posted to the gentoo-core mailing list.

Status updates are very important to the proper functioning of our management structure. Currently, managers make an effort to email each other weekly status updates. Soon, we hope to post weekly status updates to our respective project pages so that the public can be apprised on the status of every top-level project.

Decision-making

Currently, GLEPs (Gentoo Linux Enhancement Proposals) can be approved or rejected by the appropriate top-level manager under which the GLEP falls. If there is no clearly-defined manager under which the GLEP falls, the GLEP will be voted upon by the Managers and Chief Architect, and must be approved unanimously. In all cases, a public, written explanation must be provided detailing why the GLEP was approved or rejected, either by the manager who approved/rejected it, or the head of the GLEP sub-project (Grant Goodyear) if the GLEP was voted upon by the management team. This summary is meant to reflect the decision that was made by some of the managers at an early manager meeting.

Currently, there is no formal general voting procedure in place. In the interim, any item to be voted upon must be approved by "votable" by the Chief Architect. Before voting takes place, all managers must have an opportunity to present their ideas before the other managers, with the general originator(s) of the idea having the opportunity to present first. After that, the Chief Architect and Managers can present their ideas, with the Chief Architect having the opportunity to present last. After this has happened, voting can take place, and the item will be approved on an unanimous vote. Managers or the Chief Architect can choose to abstain from voting, and the vote can still pass with abstainers as long as at least 50% of the members have voted. The voting must take place at an official managers meeting. Non-attending managers are allowed to vote via email. The vote must be officially tallied and posted to the managers list.

The reason for the "Chief Architect approval" clause it to prevent the voting process from being abused by allowing voting items that make no sense, such as those that begin with a "Should we continue to," where a "nay" result would result in a change in existing policy, as well as preventing managers for requesting that every small decision be voted upon. We currently have no clear policy to determine what is a "votable" item, and without this policy there needs to be some method to determine what is "votable" and what affects some immutable part of Gentoo.

This section is subject to additional clarification and refinement in the future, as is the rest of this document. The purpose of this section is to document our currently-existing procedures rather than define ideal or "final" procedures.

Top-level projects

It is the responsibility of the metastructure top-level project to officially document and get changes approved to our management structure. The official top-level project list can be viewed, and can be expected to change/expand slightly at the new management structure is implemented.

The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license.