

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.1 - (show annotations) (download)
Thu Sep 1 16:31:57 2005 UTC (8 years, 10 months ago) by g2boojum
Branch: MAIN
File MIME type: text/plain
new metastructure glep

1 GLEP: 39
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
14 Abstract
15 ========
17 GLEP 4 is replaced with a new "metastructure" that retains established
19 Council" to handle global (cross-project) issues.
21 Motivation
22 ==========
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
31 For example, a frequent comment that has been heard is that many Gentoo devs
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
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
40 a minimal proposal for those who remembers the "good ol' days" and thinks
41 things aren't really so different now.
43 Synopsis of the current system:
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.
67 Problems with the existing system:
69 1. The assumption that TLPs are complete is either incorrect (there
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.
88 Here's a couple of additional problems identified by the current
89 metastructure reform proposals:
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.
96 Specification
101 of goals).
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
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``.
121 B. Global issues will be decided by an elected Gentoo council.
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
144 is then reset from that point.
145 * Disciplinary actions may be appealed to the council.
147 Rationale
148 =========
150 So, does this proposal solve any of the previously-mentioned problems?
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.
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
166 somebody to take the job!).
168 3. If the council does a lousy job handling global issues (or has no
169 global vision), vote out the bums.
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.
175 5. An appeal process should make disciplinary enforcement both less
176 capricious and more palatable.
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
183 problem is understaffed herds, but more organization is not necessarily a
184 solution.
187 project shouldn't require "metastructure reform", although with the
188 current system it does. With this proposal it wouldn't.
190 8. This proposal has nothing to say about GLEPs.
193 Copyright
194 =========
196 This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20