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