en/glep/glep-0039.txt

GLEP: 39
Title: An "old-school" metastructure proposal with "boot for being a slacker" 
Version: $Revision: 1.3 $
Last-Modified: $Date: 2005/07/06 16:07:25 $
Author: Grant Goodyear <g2boojum@gentoo.org>,
        Ciaran McCreesh <ciaranm@gentoo.org>,
Status: Accepted
Type: Informational
Content-Type: text/x-rst
Created: 01-Sep-2005
Post-History: 01-Sep-2005


Abstract
========

GLEP 4 is replaced with a new "metastructure" that retains established
projects (and makes new projects easier to create), but adds a new "Gentoo
Council" to handle global (cross-project) issues.

Motivation
==========

The Fosdem and subsequent reform proposals shepherded by Koon are thorough,
extremely detailed, and somewhat complicated.  They have a lot of good ideas.
For many who have been with Gentoo a long time, though, there's just something
about them that they don't really like.  More than a few Gentoo devs are
almost entirely uninterested in metastructure as long as it doesn't get in
their way, and because the current proposals impose at least some order on our
unruly devs these proposals are guaranteed to "get in the way" to some degree.
For example, a frequent comment that has been heard is that many Gentoo devs
don't know who his/her manager (or project lead) is, which is a clear
indication that our current system is broken.  The existing proposals solve
the problem by requiring that each dev belong to a project.  Perhaps the part
that is broken, though, is the belief that every dev should have a manager.
The history of Gentoo is such that traditionally big advances have often been
implemented by a single or a small number of dedicated devs (thus our
long-standing tradition that devs have access to the entire tree), and surely
we do not want to make things harder (or less fun) for such people.  So here's
a minimal proposal for those who remembers the "good ol' days" and thinks
things aren't really so different now.

Synopsis of the current system:

  *  There are 13-15 top-level projects (TLPs).  Top-level projects are
     comprised of sub-projects, and the goal was that every Gentoo
     project would be a sub-project of one of the TLPs.  Supposedly each
     dev therefore belongs to one or more TLPs.
  *  Each TLP has at least a "strategic" manager, and potentially also an
     "operational" manager.  Only the strategic managers vote on global
     Gentoo issues.
  *  The managers of each TLP were appointed by drobbins, the other
     TLP managers, or elected by their project members.  These managers
     have no set term.
  *  Within each TLP the managers are responsible for making decisions
     about the project, defining clear goals, roadmaps, and timelines
     for the project, and solving problems that arise within the TLP
     (see GLEP 4 for the specific list).
  *  The strategic TLP managers are also responsible for deciding issues that
     affect Gentoo across project lines.  The primary mechanism for
     handling global-scope issues is the managers' meetings.
  *  Disciplinary action taken against erring devs is handled by the
     "devrel" TLP, unless the dev is a strategic TLP manager.  In that
     case disciplinary action must be enacted by the other strategic TLP
     managers.

Problems with the existing system:

1. The assumption that TLPs are complete is either incorrect (there
   still is no "server" TLP) or just plain weird (but the lack of a
   server TLP is technically okay because all devs who don't have an
   obvious TLP belong to the "base" TLP by default).  
2. There is nothing at all to ensure that project leads actually do
   represent the devs they supposedly lead or satisfy their
   responsibilities.  Indeed, should a TLP manager go AWOL it is not at
   all obvious how the situation should be resolved.
3. Nothing is being decided at global scope right now.  Some TLP strategic 
   managers rarely attend the managers' meetings, and the managers as a
   whole certainly are not providing any sort of global vision for
   Gentoo right now.
4. Even if the strategic TLP managers were making global decisions for
   Gentoo, the TLP structure is such that almost all devs fall under
   only one or two TLPs.  Thus voting on global issues is hardly
   proportional, and thus many devs feel disenfranchised.
5. Regardless of whether or not it is justified, devrel is loathed by
   many in its enforcement role.

Here's a couple of additional problems identified by the current
metastructure reform proposals:

6. The current system has no mechanism for identifying either projects
   or devs that have gone inactive.
7. Bugs that cut across projects often remain unresolved.
8. GLEPs often linger in an undetermined state.

Specification
=============


A.  A project is a group of developers working towards a goal (or a set
    of goals).

      *  A project exists if it has a web page at
         www.g.o/proj/en/whatever that is maintained.  ("Maintained" means
         that the information on the page is factually correct and not
         out-of-date.)  If the webpage isn't maintained, it is presumed dead.  
      *  It may have one or many leads, and the leads are
         selected by the members of the project.  This selection must
         occur at least once every 12 months, and may occur at any
         time.
      *  It may have zero or more sub-projects.  Sub-projects are
         just projects that provide some additional structure, and their
         web pages are in the project's space.
      *  Not everything (or everyone) needs a project.  
      *  Projects need not be long-term.
      *  Projects may well conflict with other projects.  That's okay.
      *  Any dev may create a new project just by creating a new page
         (or, more realistically, directory and page) in
         ``gentoo/xml/htdocs/proj/en``.

B.  Global issues will be decided by an elected Gentoo council.

      *  There will be a set number of council members.  (For the
         first election that number was set to 7 by acclamation.)
      *  Council members will be chosen by a general election of all
         devs once per year.
      *  The council must hold an open meeting at least once per month.
      *  Council decisions are by majority vote of those who show up (or
         their proxies).
      *  If a council member (or their appointed proxy) fails to show up for
         two consecutive meetings, they are marked as a slacker.
      *  If a council member who has been marked a slacker misses any further
         meeting (or their appointed proxy doesn't show up), they lose their
         position and a new election is held to replace that person. The newly
         elected council member gets a 'reduced' term so that the yearly
         elections still elect a full group.
      *  Council members who have previously been booted for excessive slacking
         may stand for future elections, including the election for their
         replacement. They should, however, justify their slackerness, and
         should expect to have it pointed out if they don't do so themselves.
      *  The 'slacker' marker is reset when a member is elected.
      *  If any meeting has less than 50% attendance by council members, a new
         election for *all* places must be held within a month. The 'one year'
         is then reset from that point.
      *  Disciplinary actions may be appealed to the council.

Rationale
=========

So, does this proposal solve any of the previously-mentioned problems?  

1. There is no longer any requirement that the project structure be
complete.  Some devs work on very specific parts of the tree, while
some work on practically everything; neither should be shoehorned into
an ad-hoc project structure.  Moreover, it should be easy to create new
projects where needed (and remove them when they are not), which this
proposal should enable.

2. By having the members choose their project leads periodically, the
project leads are necessarily at least somewhat responsible (and hopefully
responsive) to the project members.  This proposal has removed the list of
responsibilities that project leads were supposed to satisfy, since hardly
anybody has ever looked at the original list since it was written.  Instead
the practical responsibility of a lead is "whatever the members require", and
if that isn't satisfied, the members can get a new lead (if they can find
somebody to take the job!).

3. If the council does a lousy job handling global issues (or has no
global vision), vote out the bums.  

4. Since everybody gets to vote for the council members, at least in
principle the council members represent all developers, not just a
particular subset.

5. An appeal process should make disciplinary enforcement both less
capricious and more palatable.

6. This proposal doesn't help find inactive devs or projects.  It
really should not be that much of a problem.  We already have a script for
identifying devs who haven't made a CVS commit within a certain period of
time.  As for moribund projects, if the project page isn't maintained, it's
dead, and we should remove it.  That, too, could be automated.  A much bigger
problem is understaffed herds, but more organization is not necessarily a
solution.

7. The metabug project is a great idea.  Let's do that!  Adding a useful
project shouldn't require "metastructure reform", although with the
current system it does.  With this proposal it wouldn't.

8. This proposal has nothing to say about GLEPs.


Copyright
=========

This document has been placed in the public domain.

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