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 |
|
|
|