Project:Council/Metastructure reform 2005/Oldschool

From Gentoo Wiki
Jump to:navigation Jump to:search

An "old-school" metastructure proposal

The Fosdem and subsequent reform proposals shepherded by Koon are thorough, extremely detailed, and somewhat complicated. I think they have a lot of good ideas. As somebody who's been with Gentoo a long time, though, there's just something about them that I don't really like. More than a few Gentoo devs are almost entirely uninterested in metastructure as long as it doesn't get in their way, and because the current proposals impose at least some order on our unruly devs these proposals are guaranteed to "get in the way" to some degree. For example, a frequent comment that I have heard is that many Gentoo devs don't know who his/her manager (or project lead) is, which is a clear indication that our current system is broken. The existing proposals solve the problem by requiring that each dev belong to a project. In my opinion the part that is broken is the belief that every dev should have a manager. The history of Gentoo is such that traditionally big advances have often been implemented by a single or a small number of dedicated devs (thus our long-standing tradition that devs have access to the entire tree), and I strongly believe that we do not want to make things harder (or less fun) for such people. So here's a minimal proposal from somebody who remembers the "good ol' days" and thinks things aren't really so different now.

Synopsis of the current system:

  • There are 13-15 top-level projects (TLPs). Top-level projects are comprised of sub-projects, and the goal was that every Gentoo project would be a sub-project of one of the TLPs. Supposedly each dev therefore belongs to one or more TLPs.
  • Each TLP has at least a "strategic" manager, and potentially also an "operational" manager. Only the strategic managers vote on global Gentoo issues.
  • The managers of each TLP were appointed by drobbins, the other TLP managers, or elected by their project members. These managers have no set term.
  • Within each TLP the managers are responsible for making decisions about the project, defining clear goals, roadmaps, and timelines for the project, and solving problems that arise within the TLP (see GLEP 4 for the specific list).
  • The strategic TLP managers are also responsible for deciding issues that affect Gentoo across project lines. The primary mechanism for handling global-scope issues is the managers' meetings.
  • Disciplinary action taken against erring devs is handled by the "devrel" TLP, unless the dev is a strategic TLP manager. In that case disciplinary action must be enacted by the other strategic TLP managers.

Problems with the existing system:

  1. The assumption that TLPs are complete is either incorrect (there still is no "server" TLP) or just plain weird (but the lack of a server TLP is technically okay because all devs who don't have an obvious TLP belong to the "base" TLP by default).
  2. There is nothing at all to ensure that project leads actually do represent the devs they supposedly lead or satisfy their responsibilities. Indeed, should a TLP manager go AWOL it is not at all obvious how the situation should be resolved.
  3. Nothing is being decided at global scope right now. Some TLP strategic managers rarely attend the managers' meetings, and the managers as a whole certainly are not providing any sort of global vision for Gentoo right now.
  4. Even if the strategic TLP managers were making global decisions for Gentoo, the TLP structure is such that almost all devs fall under only one or two TLPs. Thus voting on global issues is hardly proportional, and thus many devs feel disenfranchised.
  5. Regardless of whether or not it is justified, devrel is loathed by many in its enforcement role.

Here's a couple of additional problems identified by the current metastructure reform proposals:

  1. The current system has no mechanism for identifying either projects or devs that have gone inactive.
  2. Bugs that cut across projects often remain unresolved.
  3. GLEPs often linger in an undetermined state.

Naively simple reform proposal:

  1. 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.g.o/proj/en/whatever that is maintained. 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.
  2. Global issues will be decided by an elected Gentoo council.
    • There will be a set number of council members. I like 7, myself, but not for any particularly good reason.
    • 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).
    • Disciplinary actions may be appealed to the council.

So, does this proposal solve any of the above problems? Well, I think so, of course, but here's my reasoning.

  1. There is no longer any requirement that the project structure be complete. Some devs work on very specific parts of the tree, while some work on practically everything; neither should be shoehorned into an ad-hoc project structure. Moreover, it should be easy to create new projects where needed (and remove them when they are not), and I think this proposal does that.
  2. By having the members choose their project leads periodically, the project leads are necessarily at least somewhat responsible to the project members. I've also removed the list of responsibilities that project leads are supposed to satisfy, since hardly anybody has ever looked at the original list since it was written. Instead 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!).
  3. If the council does a lousy job handling global issues (or has no global vision), vote out the bums.
  4. Since everybody gets to vote for the council members, everybody is represented.
  5. An appeal process should make disciplinary enforcement both less capricious and more palatable.
  6. My proposal doesn't help find inactive devs or projects. I don't think it's that much of a problem. We already have a script for identifying devs who haven't made a CVS commit within a certain period of time. As for moribund projects, if the project page isn't maintained, it's dead, and we should remove it. That, too, could be automated. A much bigger problem is understaffed herds, but I don't think that more organization is necessarily a solution.
  7. The metabug project is a great idea. Let's do that! Adding a useful project shouldn't require "metastructure reform", although with the current system it does. With my proposal it wouldn't.
  8. My proposal has nothing to say about GLEPs.

This page is based on a document formerly found on our main website
The following people contributed to the original document: Grant Goodyear
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.

This document has been placed in the public domain.