/[gentoo]/xml/htdocs/proj/en/glep/glep-0039.txt
Gentoo

Contents of /xml/htdocs/proj/en/glep/glep-0039.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.3 - (show annotations) (download)
Fri Oct 12 02:08:27 2007 UTC (6 years, 11 months ago) by antarus
Branch: MAIN
Changes since 1.2: +3 -2 lines
File MIME type: text/plain
Add glep 54, to replace (and require) glep 39, regarding project announcements and RFCs.  I'm marking this as F (final) as it was approved ages ago; feel free to take up wording and merits with me and it will be edited after the fact.  If you have a problem with this process, again take it up with me as I'm the bastard that did it.  Thanks

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

  ViewVC Help
Powered by ViewVC 1.1.20