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 |