Gentoo Archives: gentoo-project

From: Richard Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Subject: [gentoo-project] Gentoo Leadership Structure
Date: Mon, 19 May 2008 23:47:13
Message-Id: 48321161.1060901@gentoo.org
1 I was thinking a little of some of pros/cons of how Gentoo is organized,
2 and maybe a few steps would help to improve it a little. I'd consider
3 this really to just be an item for discussion in terms of longer-term
4 goals - not something that we should try to institute as a knee-jerk
5 response to the current GLEP 39 debate.
6
7 First - let's talk about what works well currently:
8
9 1. Devs are represented democratically.
10 2. The consensus-based approach tends to ensure that really
11 objectionable decisions aren't made.
12 3. The process is pretty informal and "fun" - we don't obsess over
13 Parliamentary Procedure and Robert's Rules of Order.
14 4. For the most part anybody can go ahead and just create a project or
15 initiative or overlay and do whatever they want as long as it doesn't
16 have a big impact on the distro / portage tree. In a sense the council
17 can seem a little boring since for many things they aren't actually needed.
18 5. The day-to-day operations are managed by independent and functional
19 teams. They tend to get along and stuff gets done without a chain of
20 command.
21
22 So, what do I perceive as some of the issues? Note that I don't think
23 these reflect on the individuals involve so much as the processes. Note
24 also that some of these are more of perception issues, but perceptions
25 matter too.
26
27 1. The council can seem a bit aloof during important conversations.
28 Granted, we don't want knee-jerk reactions, but I think some involvement
29 would help steady the helm during controversy.
30
31 2. It is difficult to set long-term direction with a committee at the
32 helm.
33
34 3. A committee doesn't really have an inspirational role - right now
35 project leads are likely filling this role.
36
37 4. When really big issues come up there are questions of whether the
38 council should act on its own.
39
40 5. There are still open questions regarding the division between the
41 trustees and the council when it comes to issues other than handling of
42 assets and technical decisions.
43
44 So, how do I propose to help sort these issues out? Well, I was
45 thinking that we don't need to revolutionize the current process,
46 because I think the current process largely works. However, I do
47 propose a few changes:
48
49 1. The council should be able to appoint a leader from its own ranks
50 (and a backup). This role would be like a prime minister in most
51 parliamentary democracies. They are really just a figurehead/spokesman,
52 but they are at least a go-to person who can claim to speak for the
53 council. They can make decisions autonomously, but all binding
54 decisions must be ratified by the council. They can be appointed and
55 de-appointed as needed and rotations could also be used (perhaps
56 rotating somebody in to the backup role first and then onto the lead role).
57
58 2. The council would be the leaders of the distro with respect to all
59 issues that don't involve anything that is legally Gentoo Foundation
60 property. The Foundation has to operate in compliance with various
61 laws, and I think it is best to allow them to focus on Foundation issues
62 so that legalities don't get in the way of issues that don't need to
63 involve them. That doesn't prevent the Foundation from having an
64 advocacy role or a voice - but since both the council and the foundation
65 have a democratic mandate why pick the more formal of the two to resolve
66 issues in what is a reasonably small body of members? The argument has
67 been made that the council has technical expertise, while the trustees
68 have broader expertise - I'm not sure I agree. The expertise of the two
69 boards differs, but both have a particular focus (technical vs legal) -
70 neither has a general management focus but perhaps that could change. I
71 also want to comment that I don't want to see these two bodies in
72 conflict - neither has the role of being the voice of the "community" in
73 a way that the other does not. If we get into a mode where we have two
74 leadership bodies in conflict I think it will be a net loss for Gentoo -
75 we can't function if we have the Foundation repossessing hardware, and
76 we can't function if devs start quitting because they feel like they're
77 being treated as subservient to the "community".
78
79 3. Council will meet monthly, but any slacker policies will be at its
80 own discretion. Accountability to devs will be handled in a different
81 way that is a bit more flexible. Official decisions and votes must be
82 made in scheduled meetings, although the public may be excluded for
83 issues that are personal in nature at its discretion. Meetings must be
84 clearly announced at least one week in advance on -dev-announce except
85 in emergencies. No definition here - accountability is handled in the
86 next item.
87
88 4. Any developer may follow the following procedure to hold a
89 referendum on any issue that will be binding on Gentoo (but not the
90 Foundation):
91
92 a. Create a petition containing a clear resolution with voting options
93 (which must include an option to abstain and an option to decline the
94 resolution).
95
96 b. Collect gpg signatures from developers/staff. The requisite number
97 of signatures is 10% of the number devs who made commits in the last 30
98 days. Note that the count of devs making commits is used ONLY to
99 determine the number of sigs needed - any devs/staff can provide sigs
100 regardless of their role or level of activity as long as they haven't
101 been retired/booted.
102
103 c. Submit petition to council@g.o. The council will post the petition
104 on -dev-announce (or -core if the petition so indicates) and allow two
105 weeks for debate and two weeks for voting.
106
107 Note that the referendum process is intended to be rare (maybe the
108 threshold should be 20% or more). It could be used to impeach council
109 members, make a decision, etc. The council would be bound to execute
110 the decision as best they are able. If the council doesn't do a good
111 job they could be impeached/etc - I think that is the best we can do
112 since ultimately we're depending on humans to do the right thing, and
113 the last thing we want is multiple councils with checks and balances and
114 more debate than action any time we want to do something.
115
116 Such a system would handle all of the current controversies fairly well
117 I think, although I don't think this should be enacted as a reactionary
118 step. In fact, this is really just food for thought, and perhaps
119 anything that does get enacted will look quite different.
120
121 I almost hesitate to do this, but here are some practical examples of
122 how this would eliminate perceived ambiguity in some of the current issues:
123
124 1. Council tells devrel lead that they can take "emergency" action to
125 terminate a dev on their own initiative. Devrel lead does so. In the
126 proposed model there is nothing to question - the Council does indeed
127 have the power to delegate such matters (assuming it formally voted or
128 the new lead role took the action with ratification), and anybody acting
129 with council authority is legit.
130
131 2. Council has direct involvement in a dismissal but takes the appeal.
132 In the proposed model this is also fine - the council is still the
133 last line of appeal (short of taking an appeal to the -dev mailing list
134 to stir up support for a petition).
135
136 3. A bunch of devs argue the council acted wrongly and want to take
137 action. Under the new model instead of arguing about missed meetings a
138 petition is circulated and if enough people care a referendum takes
139 place. The petition could call for reinstating the devs and putting
140 them through the normal devrel process, or for new elections to take
141 place, or whatever. If petition doesn't get sufficient support then it
142 dies on the vine, and at least everybody can agree that there was due
143 process. The burden of collecting sigs is on those who want to petition
144 the distro - so the council isn't stuck dealing with the mess if they
145 think they can just ignore it and it will go away. On the other hand,
146 there is no longer a question as to what constitutes sufficient
147 authority to call for a vote - anybody can inspect a petition and see
148 that it has the appropriate number of sigs if they care to do so.
149
150 4. Council members miss a meeting - do we boot them all? Under the new
151 model no such action is automatic unless the council imposes those rules
152 upon itself, and the council writes the rules and can choose to break or
153 follow them with impunity. However, if devs get fed up with the council
154 a petition can be circulated.
155
156 Of course, any or none of these items could be taken and adopted in
157 part, and they could be implemented piecemeal as well. I'm really
158 hesitant regarding referendums - we don't want every other issue
159 prompting a global vote, and we don't want leaders afraid to take action
160 lest they have to deal with everybody second-guessing them.
161
162 Well, now that I've managed to be more verbose than Duncan (whose posts
163 I admire even if I do usually skim them), I'll stand back and let
164 everybody poke holes in this...
165 --
166 gentoo-project@l.g.o mailing list

Replies

Subject Author
Re: [gentoo-project] Gentoo Leadership Structure "William L. Thomson Jr." <wltjr@g.o>
Re: [gentoo-project] Gentoo Leadership Structure Alistair Bush <ali_bush@g.o>
Re: [gentoo-project] Gentoo Leadership Structure "Jorge Manuel B. S. Vicetto" <jmbsvicetto@g.o>