| 1 |
g2boojum |
1.1 |
GLEP: 39
|
| 2 |
|
|
Title: An "old-school" metastructure proposal with "boot for being a slacker"
|
| 3 |
|
|
Version: $Revision: 1.3 $
|
| 4 |
|
|
Last-Modified: $Date: 2005/07/06 16:07:25 $
|
| 5 |
|
|
Author: Grant Goodyear <g2boojum@gentoo.org>,
|
| 6 |
|
|
Ciaran McCreesh <ciaranm@gentoo.org>,
|
| 7 |
|
|
Status: Accepted
|
| 8 |
|
|
Type: Informational
|
| 9 |
|
|
Content-Type: text/x-rst
|
| 10 |
|
|
Created: 01-Sep-2005
|
| 11 |
|
|
Post-History: 01-Sep-2005
|
| 12 |
|
|
|
| 13 |
|
|
|
| 14 |
|
|
Abstract
|
| 15 |
|
|
========
|
| 16 |
|
|
|
| 17 |
|
|
GLEP 4 is replaced with a new "metastructure" that retains established
|
| 18 |
|
|
projects (and makes new projects easier to create), but adds a new "Gentoo
|
| 19 |
|
|
Council" to handle global (cross-project) issues.
|
| 20 |
|
|
|
| 21 |
|
|
Motivation
|
| 22 |
|
|
==========
|
| 23 |
|
|
|
| 24 |
|
|
The Fosdem and subsequent reform proposals shepherded by Koon are thorough,
|
| 25 |
|
|
extremely detailed, and somewhat complicated. They have a lot of good ideas.
|
| 26 |
|
|
For many who have been with Gentoo a long time, though, there's just something
|
| 27 |
|
|
about them that they don't really like. More than a few Gentoo devs are
|
| 28 |
|
|
almost entirely uninterested in metastructure as long as it doesn't get in
|
| 29 |
|
|
their way, and because the current proposals impose at least some order on our
|
| 30 |
|
|
unruly devs these proposals are guaranteed to "get in the way" to some degree.
|
| 31 |
|
|
For example, a frequent comment that has been heard is that many Gentoo devs
|
| 32 |
|
|
don't know who his/her manager (or project lead) is, which is a clear
|
| 33 |
|
|
indication that our current system is broken. The existing proposals solve
|
| 34 |
|
|
the problem by requiring that each dev belong to a project. Perhaps the part
|
| 35 |
|
|
that is broken, though, is the belief that every dev should have a manager.
|
| 36 |
|
|
The history of Gentoo is such that traditionally big advances have often been
|
| 37 |
|
|
implemented by a single or a small number of dedicated devs (thus our
|
| 38 |
|
|
long-standing tradition that devs have access to the entire tree), and surely
|
| 39 |
|
|
we do not want to make things harder (or less fun) for such people. So here's
|
| 40 |
|
|
a minimal proposal for those who remembers the "good ol' days" and thinks
|
| 41 |
|
|
things aren't really so different now.
|
| 42 |
|
|
|
| 43 |
|
|
Synopsis of the current system:
|
| 44 |
|
|
|
| 45 |
|
|
* There are 13-15 top-level projects (TLPs). Top-level projects are
|
| 46 |
|
|
comprised of sub-projects, and the goal was that every Gentoo
|
| 47 |
|
|
project would be a sub-project of one of the TLPs. Supposedly each
|
| 48 |
|
|
dev therefore belongs to one or more TLPs.
|
| 49 |
|
|
* Each TLP has at least a "strategic" manager, and potentially also an
|
| 50 |
|
|
"operational" manager. Only the strategic managers vote on global
|
| 51 |
|
|
Gentoo issues.
|
| 52 |
|
|
* The managers of each TLP were appointed by drobbins, the other
|
| 53 |
|
|
TLP managers, or elected by their project members. These managers
|
| 54 |
|
|
have no set term.
|
| 55 |
|
|
* Within each TLP the managers are responsible for making decisions
|
| 56 |
|
|
about the project, defining clear goals, roadmaps, and timelines
|
| 57 |
|
|
for the project, and solving problems that arise within the TLP
|
| 58 |
|
|
(see GLEP 4 for the specific list).
|
| 59 |
|
|
* The strategic TLP managers are also responsible for deciding issues that
|
| 60 |
|
|
affect Gentoo across project lines. The primary mechanism for
|
| 61 |
|
|
handling global-scope issues is the managers' meetings.
|
| 62 |
|
|
* Disciplinary action taken against erring devs is handled by the
|
| 63 |
|
|
"devrel" TLP, unless the dev is a strategic TLP manager. In that
|
| 64 |
|
|
case disciplinary action must be enacted by the other strategic TLP
|
| 65 |
|
|
managers.
|
| 66 |
|
|
|
| 67 |
|
|
Problems with the existing system:
|
| 68 |
|
|
|
| 69 |
|
|
1. The assumption that TLPs are complete is either incorrect (there
|
| 70 |
|
|
still is no "server" TLP) or just plain weird (but the lack of a
|
| 71 |
|
|
server TLP is technically okay because all devs who don't have an
|
| 72 |
|
|
obvious TLP belong to the "base" TLP by default).
|
| 73 |
|
|
2. There is nothing at all to ensure that project leads actually do
|
| 74 |
|
|
represent the devs they supposedly lead or satisfy their
|
| 75 |
|
|
responsibilities. Indeed, should a TLP manager go AWOL it is not at
|
| 76 |
|
|
all obvious how the situation should be resolved.
|
| 77 |
|
|
3. Nothing is being decided at global scope right now. Some TLP strategic
|
| 78 |
|
|
managers rarely attend the managers' meetings, and the managers as a
|
| 79 |
|
|
whole certainly are not providing any sort of global vision for
|
| 80 |
|
|
Gentoo right now.
|
| 81 |
|
|
4. Even if the strategic TLP managers were making global decisions for
|
| 82 |
|
|
Gentoo, the TLP structure is such that almost all devs fall under
|
| 83 |
|
|
only one or two TLPs. Thus voting on global issues is hardly
|
| 84 |
|
|
proportional, and thus many devs feel disenfranchised.
|
| 85 |
|
|
5. Regardless of whether or not it is justified, devrel is loathed by
|
| 86 |
|
|
many in its enforcement role.
|
| 87 |
|
|
|
| 88 |
|
|
Here's a couple of additional problems identified by the current
|
| 89 |
|
|
metastructure reform proposals:
|
| 90 |
|
|
|
| 91 |
|
|
6. The current system has no mechanism for identifying either projects
|
| 92 |
|
|
or devs that have gone inactive.
|
| 93 |
|
|
7. Bugs that cut across projects often remain unresolved.
|
| 94 |
|
|
8. GLEPs often linger in an undetermined state.
|
| 95 |
|
|
|
| 96 |
|
|
Specification
|
| 97 |
|
|
=============
|
| 98 |
|
|
|
| 99 |
|
|
|
| 100 |
|
|
A. A project is a group of developers working towards a goal (or a set
|
| 101 |
|
|
of goals).
|
| 102 |
|
|
|
| 103 |
|
|
* A project exists if it has a web page at
|
| 104 |
|
|
www.g.o/proj/en/whatever that is maintained. ("Maintained" means
|
| 105 |
|
|
that the information on the page is factually correct and not
|
| 106 |
|
|
out-of-date.) If the webpage isn't maintained, it is presumed dead.
|
| 107 |
|
|
* It may have one or many leads, and the leads are
|
| 108 |
|
|
selected by the members of the project. This selection must
|
| 109 |
|
|
occur at least once every 12 months, and may occur at any
|
| 110 |
|
|
time.
|
| 111 |
|
|
* It may have zero or more sub-projects. Sub-projects are
|
| 112 |
|
|
just projects that provide some additional structure, and their
|
| 113 |
|
|
web pages are in the project's space.
|
| 114 |
|
|
* Not everything (or everyone) needs a project.
|
| 115 |
|
|
* Projects need not be long-term.
|
| 116 |
|
|
* Projects may well conflict with other projects. That's okay.
|
| 117 |
|
|
* Any dev may create a new project just by creating a new page
|
| 118 |
|
|
(or, more realistically, directory and page) in
|
| 119 |
|
|
``gentoo/xml/htdocs/proj/en``.
|
| 120 |
|
|
|
| 121 |
|
|
B. Global issues will be decided by an elected Gentoo council.
|
| 122 |
|
|
|
| 123 |
|
|
* There will be a set number of council members. (For the
|
| 124 |
|
|
first election that number was set to 7 by acclamation.)
|
| 125 |
|
|
* Council members will be chosen by a general election of all
|
| 126 |
|
|
devs once per year.
|
| 127 |
|
|
* The council must hold an open meeting at least once per month.
|
| 128 |
|
|
* Council decisions are by majority vote of those who show up (or
|
| 129 |
|
|
their proxies).
|
| 130 |
|
|
* If a council member (or their appointed proxy) fails to show up for
|
| 131 |
|
|
two consecutive meetings, they are marked as a slacker.
|
| 132 |
|
|
* If a council member who has been marked a slacker misses any further
|
| 133 |
|
|
meeting (or their appointed proxy doesn't show up), they lose their
|
| 134 |
|
|
position and a new election is held to replace that person. The newly
|
| 135 |
|
|
elected council member gets a 'reduced' term so that the yearly
|
| 136 |
|
|
elections still elect a full group.
|
| 137 |
|
|
* Council members who have previously been booted for excessive slacking
|
| 138 |
|
|
may stand for future elections, including the election for their
|
| 139 |
|
|
replacement. They should, however, justify their slackerness, and
|
| 140 |
|
|
should expect to have it pointed out if they don't do so themselves.
|
| 141 |
|
|
* The 'slacker' marker is reset when a member is elected.
|
| 142 |
|
|
* If any meeting has less than 50% attendance by council members, a new
|
| 143 |
|
|
election for *all* places must be held within a month. The 'one year'
|
| 144 |
|
|
is then reset from that point.
|
| 145 |
|
|
* Disciplinary actions may be appealed to the council.
|
| 146 |
|
|
|
| 147 |
|
|
Rationale
|
| 148 |
|
|
=========
|
| 149 |
|
|
|
| 150 |
|
|
So, does this proposal solve any of the previously-mentioned problems?
|
| 151 |
|
|
|
| 152 |
|
|
1. There is no longer any requirement that the project structure be
|
| 153 |
|
|
complete. Some devs work on very specific parts of the tree, while
|
| 154 |
|
|
some work on practically everything; neither should be shoehorned into
|
| 155 |
|
|
an ad-hoc project structure. Moreover, it should be easy to create new
|
| 156 |
|
|
projects where needed (and remove them when they are not), which this
|
| 157 |
|
|
proposal should enable.
|
| 158 |
|
|
|
| 159 |
|
|
2. By having the members choose their project leads periodically, the
|
| 160 |
|
|
project leads are necessarily at least somewhat responsible (and hopefully
|
| 161 |
|
|
responsive) to the project members. This proposal has removed the list of
|
| 162 |
|
|
responsibilities that project leads were supposed to satisfy, since hardly
|
| 163 |
|
|
anybody has ever looked at the original list since it was written. Instead
|
| 164 |
|
|
the practical responsibility of a lead is "whatever the members require", and
|
| 165 |
|
|
if that isn't satisfied, the members can get a new lead (if they can find
|
| 166 |
|
|
somebody to take the job!).
|
| 167 |
|
|
|
| 168 |
|
|
3. If the council does a lousy job handling global issues (or has no
|
| 169 |
|
|
global vision), vote out the bums.
|
| 170 |
|
|
|
| 171 |
|
|
4. Since everybody gets to vote for the council members, at least in
|
| 172 |
|
|
principle the council members represent all developers, not just a
|
| 173 |
|
|
particular subset.
|
| 174 |
|
|
|
| 175 |
|
|
5. An appeal process should make disciplinary enforcement both less
|
| 176 |
|
|
capricious and more palatable.
|
| 177 |
|
|
|
| 178 |
|
|
6. This proposal doesn't help find inactive devs or projects. It
|
| 179 |
|
|
really should not be that much of a problem. We already have a script for
|
| 180 |
|
|
identifying devs who haven't made a CVS commit within a certain period of
|
| 181 |
|
|
time. As for moribund projects, if the project page isn't maintained, it's
|
| 182 |
|
|
dead, and we should remove it. That, too, could be automated. A much bigger
|
| 183 |
|
|
problem is understaffed herds, but more organization is not necessarily a
|
| 184 |
|
|
solution.
|
| 185 |
|
|
|
| 186 |
|
|
7. The metabug project is a great idea. Let's do that! Adding a useful
|
| 187 |
|
|
project shouldn't require "metastructure reform", although with the
|
| 188 |
|
|
current system it does. With this proposal it wouldn't.
|
| 189 |
|
|
|
| 190 |
|
|
8. This proposal has nothing to say about GLEPs.
|
| 191 |
|
|
|
| 192 |
|
|
|
| 193 |
|
|
Copyright
|
| 194 |
|
|
=========
|
| 195 |
|
|
|
| 196 |
|
|
This document has been placed in the public domain.
|
| 197 |
|
|
|
Parent Directory
| 
Revision Log