Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] project organization

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] project organization
  • Date: Mon, 17 Apr 2006 19:15:15 -0500

On Apr 17, Robin Cook [rcook AT wyrms.net] wrote:
> Don't particularly care for the representative system that the USA uses
> either.

It's useful in keeping things moving. If we had to do a full project vote
every time we wanted to do things we'd either not vote on enough things
(which hurts having consensus) or never get anything done.

> And just because someone is not popular or whatnot to get voted a lead
> developer even though they may do a lot of work on Sourcemage their vote
> should count.

If an OSS project can't elect leadership based on development contributions
vs. simple popularity then it has problems. :-( Other projects are using
this type of model successfully. Keep in mind there's no set limit on the
total number of leads so anyone that tries to get elected and doesn't would
have stood on their own merits alone.

> You don't define super majority and is not defined on the apache web
> page.

The proposal defines it as 67% (in the voting policy; the organization doc
is meant as a 'summary' and doesn't go into those specifics):

"Removal Votes require a super (67%) majority to pass."

> Also this is not a representative system as lead developers have an
> unlimited term and as long as they are liked by the majority of the
> other lead developers there is no way to remove them.
>
> If the general developers votes are not going to count then all lead
> developers should be able to be removed by a majority vote of the
> general developers as well so that there is recourse for going against
> the majority of the general developers.

Any lead can be removed by a super majority vote of regular developers.
The process is defined as:

1) any developer (lead or not) moves that a lead be removed
2) any developer seconds this motion
3) there is a vote of the leads only
4) if the leads don't vote to remove via a super majority (67%), any
developer can move for a veto
5) the motion to veto is seconded
6) there is a vote of the non-leads only
7) if the (non-lead) developers vote via a super majority (67%) to remove
the Lead, they are removed

Yes, this is a lot of steps, but it's also completely defined and therefore
not very subject to whims.

If people think we need to establish a regular renewal vote for general
leads we can look at it, I started to write that but didn't want us to get
buried in an election every month. You also get into weird logistics about
how to handle a component lead who fails their regular lead revote, or if
component leads have both votes each year or just one, etc.

> CuZnDragon
> Robin Cook
>
> On Mon, 2006-04-17 at 17:36 -0500, Jeremy Blosser (emrys) wrote:
> > On Apr 17, Robin Cook [rcook AT wyrms.net] wrote:
> > > I have no problem with most of it except having no binding vote in the
> > > issues voting if not a lead developer.
> >
> > This is the way it is today (no one gets a binding vote in non-lead
> > elections except for the leads) and is typical of most representative-type
> > political systems. ie, depending on where you live you typically elect
> > your representative and then they go off and vote on your behalf. If they
> > do a good job you keep electing them, if not you throw them out.

Attachment: pgpCTLiNdx7YT.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page