Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

So, it's time to pick this thread up again.  :-)  If you're one of the
people that hates the "political" discussion, the good news is that there's
a proposal in here to let you just hack and not have to worry about this
stuff again.  The bad news is you may want to read just a bit more so you
can decide if you agree or not.

===========================================================================

Over the last few months (and longer), several issues related to project
organization have been raised.  These include:

- are we organized the best way to get our work done?
- we need more redundancy among the identified leaders/owners of components
  and deadlines
- we have more teams than we have people
- some people wish more things had votes
- some people wish nothing had votes
- some people don't care what has a vote as long as they don't have to be
  involved and can just hack
- our [PT]L votes are closed, some people don't like this, but some people
  "need" it
- our [PT]L votes lack auditability because of how the closed vote is
  implemented
- our voting guidelines tend to get fudged and we're lazy about various
  things 
- etc.

We had some decent discussion on this thread, but several people were
complaining about the "political noise" on the ML, and other things came
up, so it mostly stopped.  Then the issues continued to come up on things
like the Project and Grimoire TL votes, etc.  I went ahead and put together
a formal proposal on how I think we could perhaps do things better, which
I'm attaching here.  I went ahead and ran this by the TLs already and they
mostly seem to think it's a good idea, so I think it's time to bring the
thread back and see if we can finish it off.  If you reread the bit quoted
below, which met with general agreement on the ML, this is the main idea I
went for.

Under this proposal, the following things would *NOT* change:

- we would still have one project lead
- we would still have individual elected leads over major components like
  cauldron, grimoire, sorcery, tome
- all developers would still be eligible to vote for all of the above leads
  once per year
- the lead votes would still be closed
- other issues facing the project would be decided by a vote of the leads
  only
- these 'issue votes' by the leads would still be cast in the open (they
  are open when they happen now, though they are rare and essentially
  undefined)

The following things WOULD change:

- developers that didn't want to participate in votes and issues wouldn't
  have to
- the process for voting on issues would be defined and hopefully used more
  often
- there would be a process for the general developer population to veto
  anything the leads decided
- more developers would be able to be leads than just the team and project
  leads
- the developer "teams" would be replaced with just one group of
  developers, and the "Team Leads" would become "Component Leads" instead

Those last two are the biggest changes, so they deserve some discussion.
Both are mostly meant to deal with the "we have more teams than people"
issue:

> - more developers would be able to be leads than just the team and
>   project leads

The goal here is stop the trend to create a team just because we have
someone we want to make a lead.  We have developers that just want to hack
on their stuff, but we also have some that want to help with things like
goals and overall project issues and such.  There's no reason to make them
try to fit into a team lead position (or create a new team for them to
lead) just so they can get involved at that level.  Also, having more leads
will let the leads hand things off between each other more easily so that
if someone is gone, someone else can pick up for them with less of an
authorization question.

> - the developer "teams" would be replaced with just one group of
>   developers, and the "Team Leads" would become "Component Leads" instead

Right now it's really only the Grimoire Team that ever has more members
than "the Lead and someone else".  And the members of those other teams
tend to move around between components a lot anyway, just doing the work
that needs doing.  We can encourage this more by just acknowledging this is
how we really work in the official organization, so that if one
person/group is mostly busy elsewhere for a while other people can easily
work on what needs to get done so the project can move forward.  Again,
this is mostly what's discussed in the bit quoted below.  The organization
would be:

Project Lead
|
|-> Lead Team
    |-> Cauldron Lead
    |-> Grimoire Lead
    |-> Sorcery Lead
    |-> Tome Lead
    |-> General Leads
|
|-> General Developers

That's the summary of this proposal, and I think it's accurate.  The full
docs are attached.  Like Sergey I have some admiration for the voting
methods the Apache project pioneered, so you'll see some of their terms in
there, hopefully they're mostly familiar to most of you.  If not, there's a
URL in there with some general definitions.  If any of it doesn't make
sense please say so.  I'm hoping this is all seen as a good thing and
something we should do, but if not then let's talk about it.

I want to give some time for discussion on this, then depending on how it's
received I'll suggest it move forward based on the process it defines
itself: a motion, hopefully a second, and then a vote by the existing
Project and Team Leads.  Whether it passes or fails, the non-Lead
developers would then have the option to veto the Lead vote.  This is a
major change in some ways, so we should know there's agreement before we
use it or decide to drop it, and that process seems at least a decent way
to determine that.

On Feb 15, Eric Sandall [eric AT sandall.us] wrote:
> On Tue, 14 Feb 2006, Jeremy Blosser (emrys) wrote:
> > A possible arrangement based on the above would be something where we keep
> > the TLs, but not the teams... make the TLs component leads or something
> > instead, or the "council of elders" idea but with a PL still over them.
> > Basically, have the majority of developers that work on spells continue to
> > do that, then have a tier of more "free agent" types who are working on 
> > the
> > hairier stuff, then from that group have specific leads identified so we
> > continue to have ownership and oversight of the major areas instead of
> > anarchy, then a PL over them.  This arrangement would be very similar to
> > what we have now except it would allow various team members to move more
> > freely between projects as they're needed or want to, and would put a bit
> > more responsibilty on the leads to make sure their areas were progressing
> > toward their goals.  I'm mostly making this up as I type it, but it seems
> > like it might describe the kind of thing that happens naturally now.
> > Acknowledging it and actively supporting it might find us spending less
> > time spinning wheels and more time getting things done.
> 
> That's a good point. So we'd have more this structure?
>    Project Lead
>    |-> Cauldron Lead (Porting would probably move here)
>    |-> Grimoire Lead
>    |-> QA Lead (with Security being moved under here)
>    |-> Sorcery Lead
>    |-> Tome Lead (with PR being moved under here)
>    |-> Developers
> 
> That makes 5 "Teams" under the Project Lead and a group of Developers
> open for assignment, with each Lead being responsible for their components
> (e.g. Cauldron in charge of producing installers (e.g. ISOs)) and organizing
> (through mailing lists, forums, and/or IRC) the "Developers" group, where 
> any
> Developer can work on any component (given they have permission from
> the Lead of that component) and not being tied to any specific team.
> 
> I would still like the Grimoire Team to have section maintainers, but
> perhaps that could be, again, people from the Developers group asking
> the Grimoire Lead if they can maintain a section, and if Arwed says
> okay, then that Developer can add themselves to the MAINTAINER file of
> that section.
> 
> Anyone see problems with this? Shall we go ahead and do this?


Developer Organization
======================

SMGL's contributors are organized into a team of Lead Developers* and a team 
of
General Developers*.  Leads are further divided into a Project Lead, 
identified
Component Leads, and General Leads.  The Project and Component Leads may also
have Assistants.

[*For the purposes of this policy discussion we will refer to them using these
names; "Council of Elders" and "Council of Developers" has been suggested as a
an alternate name, but we'll let that sit for now and discuss the policy
details instead.]

General Developrs: 
- are defined as all non-Lead Developers listed at:
  http://www.sourcemage.org/developers
- can be added to the project and given repository access by any Lead
  Developer.
- have commit access to the various project components, at the discretion of
  the Lead over that component.
- have the option to cast a binding vote in all Lead Election votes.
- have the option to cast a non-binding vote in all other votes.
- can be removed by a super majority vote of the Lead Developers.
- can have a removal vote vetoed by a super majority vote of the General
  Developers.
- are automatically nominated and seconded for a removal vote after one year 
of
  inactivity (defined as no committed changes to any part of the project's
  source code or documentation repositories).

Lead Developers:
- are elected from among the General Developers by a simple majority vote of
  the General + Lead Developers.
- have commit access to the various project components, at the discretion of
  the Lead over that component.
- are required to cast a binding vote in all Lead Election and other votes.
- serve an unlimited term as long as they are not removed by vote.
- can be removed as Leads by a super majority vote of the other Lead
  Developers.
- can have a removal vote vetoed by a super majority vote of the General
  Developers.
- are automatically removed without vote or veto if they fail to cast any 
votes
  for two consecutive months or longer, provided there were at least two votes
  hold in that period.
- are automatically nominated and seconded for a removal vote after six months
  of inactivity (defined as no committed changes to any part of the project's
  source code or documentation repositories).
- revert to General Developers if removed.

Project and Component Leads:
- are elected from among the Lead Developers by a simple majority vote of the
  General + Lead Developers.
- remain Lead Developers.
- have primary responsibilty for and daily authority over one of the 
identified
  Project Components (or in the case of the Project Lead, the entire Project).
- are subject to the outcome of any votes affecting their Components.
- serve a one year term, with no limit on number of terms.
- can be removed as Project or Component Leads by a super majority vote of the
  other Lead Developers.
- can have a removal vote vetoed by a super majority vote of the General
  Developers.
- remain Lead Developers if removed.

Assistants:
- can be any General or Lead Developer chosen by the individual Project and
  Component Leads.
- act on behalf of and with the authority of the Lead they are assisting, at
  the Lead's discretion.
- do not receive any extra binding or non-binding vote as an Assistant.
- can cast the Lead's binding vote in their place in any vote, at the Lead's
  discretion.
- retain their own binding or non-binding individual vote for all elections
  they would otherwise be involved in.
- revert to their regular, non-assistant status if the Lead they are assisting
  steps down or is otherwise removed as Lead.

For more information on Lead elections see the Voting Policy.
Note: Several aspects of the Voting Policy are inspired by voting formats used
by other F/OSS projects, most notably the Apache project.  If you are 
unfamilar
with terms like '(non-)binding votes' or expressing a vote as '+/-1' and
'+/-0', please refer to http://www.apache.org/foundation/voting.html for some
general discussion, but keep in mind that only the usage explicitly described
in this policy is valid for Source Mage.

Voting Policy
=============

General:
- The Mailing List used for voting is sm-discuss AT lists.ibiblio.org.
- A "Developer" in this policy is any General or Lead Developer, as defined
  by the Developer Organization document, who was a Developer at the time the
  given vote began (the time the call for nominations was made or the time a
  given motion was first proposed).
- The terms "MAY", "SHOULD", "MUST", and "MUST NOT" when used in this Policy
  have the meanings assigned them in RFC 2119.  The term "WILL" is used to
  specify expectations for the voting process itself and the person(s)
  administering it.  If a vote is not held in compliance with these "WILL"
  specifications, any Developer MAY move that the current vote be invalidated
  and started over.  If the revote motion is seconded the current vote WILL be
  immediately suspended and the revote motion WILL proceed as an Issue Vote as
  described below.  If the revote motion carries (on initial vote or veto) the
  current vote WILL be started over by the relevant Lead or their Assistant(s)
  within one week of the scheduled end of the revote motion vote.
- All nominations, motions, seconds, votes, etc. MUST be GPG-signed by the
  Developer's GPG key as recorded at http://www.sourcemage.org/keysigning to 
be
  valid.

Lead Developer Votes:
- A General Developer MAY be nominated for Lead Developer at any time by any
  other Developer.
- Nominations MUST be sent to the Mailing List.
- The nomination MUST be seconded within one week of being made.
- The nomination MUST be accepted within one week of being made.
- If a nomination is seconded and accepted the Project Lead or their
  assistant(s) WILL call for a vote within two weeks of the date the 
nomination
  was made.
- Votes WILL proceed per the Lead Voting Process described below.

Project and Component Lead Votes:
- Component Lead Votes WILL occur during specific months, as follows:
  - January:   Project Lead
  - March:     Grimoire Lead
  - May:       Cauldron Lead
  - July:      Sorcery Lead
  - September: Tome Lead
- The Project Lead WILL send a call for nominations to the Mailing List the
  first week of the relevant month.
- Nominations WILL last for one week from the time the call for nominations is
  sent.
- Nominations MUST be sent to the Mailing List.
- The nomination MUST be seconded within one week of being made.
- The nomination MUST be accepted within one week of being made.
- Accepting nominees SHOULD send a message to the list explaining why they are
  running for the position and why people might want to elect them.
- Two weeks after calling for nominations, the Project Lead or their
  Assistant(s) WILL call for a vote.
- Votes WILL proceed per the Lead Voting Process described below.
- If there are no nominees or the incumbent Lead is the only accepting nominee
  they are reelected without a vote.
- The Lead's term begins the first day of the month following their election
  and lasts for one year.
- If a Project or Component Lead is removed or steps down before the end of
  their regular term, the Project Lead (or, in the case of the Project Lead
  being the one removed, any other Lead Developer) WILL call for nominations
  for a replacement within one week of the effective date of the Lead's
  removal.  The voting process for the replacement WILL continue as described
  above.  The replacement WILL at most serve out the remainder of the existing
  term for that position, and the regular vote WILL be held when scheduled.
- If at any time a Project or Component Lead position is empty (due to lack of
  available candidates, etc.), the Project Lead (or any Lead Developer, in the
  case of a Project Lead vacancy) MAY schedule a new vote for a temporary Lead
  to fill the position until the next scheduled election.  The vote will
  continue as described above.

Lead Voting Process:
- Lead votes last one week from the date they are called for.
- Votes MUST be sent via private email to the Project Lead or the Assistant 
who
  called the vote as an ordered list of the candidates or "abstain".
- Votes MUST be received at the designated email address by the scheduled end
  of the vote to be valid.
- Lead Developers MUST cast a vote.
- General Developers MAY cast a vote.
- 51% of the Lead Developers MUST cast a vote, or the vote is invalid.
- Votes require a simple (51%) majority to pass.
- If no quorom or majority is achieved, and the vote is for a Project or
  Component lead, and the incumbent is a valid candidate, they are reelected.
  If there is no incumbent or they have not accepted a nomination, the 
position
  becomes vacant.
- Within 48 hours of the receipt of a vote the vote counter WILL respond to 
the
  voter via private email with an acknowledgement of the vote and an 
anonymized
  receipt string.
- Within 72 hours of the end of the vote the vote counter WILL post the 
results
  to the Mailing List as a list of all anonymized receipt strings and the vote
  they represent.
- Any voter MAY contest the results within 72 hours of their posting.
- If contested, the vote counter WILL produce the full votes with their
  signatures and receipt strings to three other Lead Developers within 48
  hours of the contest reaching the Mailing List.
- These three Leads WILL provide their own list of receipt strings and their
  respective votes to the Mailing List within 72 hours of receiving the votes.
- If the results are still contested, the vote counter WILL provide all votes
  and their signatures and receipt strings to the Mailing List within 48 hours
  of the (second) contest.

Issue Voting Process:
- While we prefer to operate based on general consensus, votes are at times
  necessary to moves issues to resolution.  Therefore, any General or Lead
  Developer MAY move for any issue to be put to a vote.
- Motions for votes MUST be seconded within one week of being made.
- If the motion is seconded the Project Lead or their Assistant(s) WILL call
  for a vote within one week of the initial motion.
- Votes last one week from the date they are called for.
- Votes MUST be sent to the Mailing List as +1 (yes), -1 (no), +/-0 (abstain)
  or an unambiguous equivalent.  "Unambiguous" is defined at the sole
  discretion of the Project Lead.
- Lead Developers MUST cast a vote.
- General Developers MAY cast a vote, but their votes are advisory only (i.e.,
  non-binding).
- 51% of the Lead Developers MUST cast a vote, or the vote is invalid and
  fails.
- Votes require a simple (51%) majority (of all binding votes cast) to pass.
- Motions which pass are considered active immediately upon the majority vote
  reaching the Mailing List.

Developer Removal Voting Process:
- General and Lead Developer Removal Votes WILL proceed per the Issue Voting
  Process described above, with the following exceptions:
  - The Developer in question MUST NOT vote.
  - Removal Votes require a super (67%) majority to pass.
- Successful or failed removal votes MAY be vetoed by the General Developers.

General Developer Veto Process:
- The General Developers MAY veto any Developer Removal Votes and any Issue
  Votes which would modify the Project's organizational structure or Voting
  Policy.
- Motions to veto MUST reach the Mailing List within 72 hours of the scheduled
  end of the vote in question.
- Veto votes WILL proceed per the Issue Voting Process described above, with
  the following exceptions:
  - For Removal Votes, the Developer in question MUST NOT vote.
  - Lead Developers MUST NOT vote.
  - General Developers MAY cast a binding vote.
  - 51% of the General Developers MUST cast a vote, or the veto is invalid and
    fails.
  - Vetos require a super (67%) majority to pass.
- Veto votes are final.

Attachment: pgpx0w6hpRwn8.pgp
Description: PGP signature