public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-project] Gentoo Leadership Structure
@ 2008-05-19 23:46 Richard Freeman
  2008-05-20  0:32 ` William L. Thomson Jr.
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Richard Freeman @ 2008-05-19 23:46 UTC (permalink / raw
  To: gentoo-project

I was thinking a little of some of pros/cons of how Gentoo is organized,
and maybe a few steps would help to improve it a little.  I'd consider
this really to just be an item for discussion in terms of longer-term
goals - not something that we should try to institute as a knee-jerk
response to the current GLEP 39 debate.

First - let's talk about what works well currently:

1.  Devs are represented democratically.
2.  The consensus-based approach tends to ensure that really
objectionable decisions aren't made.
3.  The process is pretty informal and "fun" - we don't obsess over
Parliamentary Procedure and Robert's Rules of Order.
4.  For the most part anybody can go ahead and just create a project or
initiative or overlay and do whatever they want as long as it doesn't
have a big impact on the distro / portage tree.  In a sense the council
can seem a little boring since for many things they aren't actually needed.
5.  The day-to-day operations are managed by independent and functional
teams.  They tend to get along and stuff gets done without a chain of
command.

So, what do I perceive as some of the issues?  Note that I don't think
these reflect on the individuals involve so much as the processes.  Note
also that some of these are more of perception issues, but perceptions
matter too.

1.  The council can seem a bit aloof during important conversations.
Granted, we don't want knee-jerk reactions, but I think some involvement
would help steady the helm during controversy.

2.  It is difficult to set long-term direction with a committee at the
helm.

3.  A committee doesn't really have an inspirational role - right now
project leads are likely filling this role.

4.  When really big issues come up there are questions of whether the
council should act on its own.

5.  There are still open questions regarding the division between the
trustees and the council when it comes to issues other than handling of
assets and technical decisions.

So, how do I propose to help sort these issues out?  Well, I was
thinking that we don't need to revolutionize the current process,
because I think the current process largely works.  However, I do
propose a few changes:

1.  The council should be able to appoint a leader from its own ranks
(and a backup).  This role would be like a prime minister in most
parliamentary democracies.  They are really just a figurehead/spokesman,
but they are at least a go-to person who can claim to speak for the
council.  They can make decisions autonomously, but all binding
decisions must be ratified by the council.  They can be appointed and
de-appointed as needed and rotations could also be used (perhaps
rotating somebody in to the backup role first and then onto the lead role).

2.  The council would be the leaders of the distro with respect to all
issues that don't involve anything that is legally Gentoo Foundation
property.  The Foundation has to operate in compliance with various
laws, and I think it is best to allow them to focus on Foundation issues
so that legalities don't get in the way of issues that don't need to
involve them.  That doesn't prevent the Foundation from having an
advocacy role or a voice - but since both the council and the foundation
have a democratic mandate why pick the more formal of the two to resolve
issues in what is a reasonably small body of members?  The argument has 
been made that the council has technical expertise, while the trustees 
have broader expertise - I'm not sure I agree.  The expertise of the two 
boards differs, but both have a particular focus (technical vs legal) - 
neither has a general management focus but perhaps that could change.  I 
also want to comment that I don't want to see these two bodies in 
conflict - neither has the role of being the voice of the "community" in 
a way that the other does not.  If we get into a mode where we have two 
leadership bodies in conflict I think it will be a net loss for Gentoo - 
we can't function if we have the Foundation repossessing hardware, and 
we can't function if devs start quitting because they feel like they're 
being treated as subservient to the "community".

3.  Council will meet monthly, but any slacker policies will be at its
own discretion.  Accountability to devs will be handled in a different
way that is a bit more flexible.  Official decisions and votes must be
made in scheduled meetings, although the public may be excluded for
issues that are personal in nature at its discretion.  Meetings must be
clearly announced at least one week in advance on -dev-announce except
in emergencies.  No definition here - accountability is handled in the
next item.

4.  Any developer may follow the following procedure to hold a
referendum on any issue that will be binding on Gentoo (but not the
Foundation):

a.  Create a petition containing a clear resolution with voting options
(which must include an option to abstain and an option to decline the
resolution).

b.  Collect gpg signatures from developers/staff.  The requisite number
of signatures is 10% of the number devs who made commits in the last 30
days.  Note that the count of devs making commits is used ONLY to
determine the number of sigs needed - any devs/staff can provide sigs
regardless of their role or level of activity as long as they haven't
been retired/booted.

c.  Submit petition to council@g.o.  The council will post the petition
on -dev-announce (or -core if the petition so indicates) and allow two
weeks for debate and two weeks for voting.

Note that the referendum process is intended to be rare (maybe the
threshold should be 20% or more).  It could be used to impeach council 
members, make a decision, etc.  The council would be bound to execute 
the decision as best they are able.  If the council doesn't do a good 
job they could be impeached/etc - I think that is the best we can do 
since ultimately we're depending on humans to do the right thing, and 
the last thing we want is multiple councils with checks and balances and 
more debate than action any time we want to do something.

Such a system would handle all of the current controversies fairly well
I think, although I don't think this should be enacted as a reactionary
step.  In fact, this is really just food for thought, and perhaps
anything that does get enacted will look quite different.

I almost hesitate to do this, but here are some practical examples of
how this would eliminate perceived ambiguity in some of the current issues:

1.  Council tells devrel lead that they can take "emergency" action to 
terminate a dev on their own initiative.  Devrel lead does so.  In the 
proposed model there is nothing to question - the Council does indeed 
have the power to delegate such matters (assuming it formally voted or 
the new lead role took the action with ratification), and anybody acting 
with council authority is legit.

2.  Council has direct involvement in a dismissal but takes the appeal. 
  In the proposed model this is also fine - the council is still the 
last line of appeal (short of taking an appeal to the -dev mailing list 
to stir up support for a petition).

3.  A bunch of devs argue the council acted wrongly and want to take 
action.  Under the new model instead of arguing about missed meetings a 
petition is circulated and if enough people care a referendum takes 
place.  The petition could call for reinstating the devs and putting 
them through the normal devrel process, or for new elections to take 
place, or whatever.  If petition doesn't get sufficient support then it 
dies on the vine, and at least everybody can agree that there was due 
process.  The burden of collecting sigs is on those who want to petition 
the distro - so the council isn't stuck dealing with the mess if they 
think they can just ignore it and it will go away.  On the other hand, 
there is no longer a question as to what constitutes sufficient 
authority to call for a vote - anybody can inspect a petition and see 
that it has the appropriate number of sigs if they care to do so.

4.  Council members miss a meeting - do we boot them all?  Under the new 
model no such action is automatic unless the council imposes those rules 
upon itself, and the council writes the rules and can choose to break or 
follow them with impunity.  However, if devs get fed up with the council 
a petition can be circulated.

Of course, any or none of these items could be taken and adopted in 
part, and they could be implemented piecemeal as well.  I'm really 
hesitant regarding referendums - we don't want every other issue 
prompting a global vote, and we don't want leaders afraid to take action 
lest they have to deal with everybody second-guessing them.

Well, now that I've managed to be more verbose than Duncan (whose posts 
I admire even if I do usually skim them), I'll stand back and let 
everybody poke holes in this...
-- 
gentoo-project@lists.gentoo.org mailing list



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2008-05-20 16:38 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-19 23:46 [gentoo-project] Gentoo Leadership Structure Richard Freeman
2008-05-20  0:32 ` William L. Thomson Jr.
2008-05-20  1:43   ` Mark Loeser
2008-05-20  2:00     ` William L. Thomson Jr.
2008-05-20  5:40 ` Alistair Bush
2008-05-20 10:21   ` Jorge Manuel B. S. Vicetto
2008-05-20 11:57     ` Alistair Bush
2008-05-20 10:05 ` Jorge Manuel B. S. Vicetto
2008-05-20 10:19   ` Donnie Berkholz
2008-05-20 16:37   ` Richard Freeman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox