Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

Hello everyone,

With this e-mail I do hereby begin the Official Full Vote for the
Organization Policy to be enacted. :)

The rules are defined in our Team Lead Voting Process[0], but the
important rules are here:
  * All votes must be GPG signed with a key listed on your keysigning
page[1]
  * All votes are to be sent only to me: eric AT sandall.us (or
projectlead AT sourcemage.org if you prefer).
  * This vote will last until Thursday, May 4, 2006
  * All developers listed on the developer page[2] must vote
  * Only developers listed on the developer page[2] may vote
  * Votes are either "Yes", "No", or "Abstain". No ranking is available
    * Yes means "I want this policy"
    * No means "I do not want this policy"
    * Abstain means you do not wish to voice an opinion

Please fully read the policy documents attached (policy_developers and
policy_voting) before voting.

-sandalle

[0] http://www.sourcemage.org/TeamLeadVotingProcess
[1] http://www.sourcemage.org/keysigning
[2] http://www.sourcemage.org/developers

-- 
Eric Sandall                     |  Source Mage GNU/Linux Developer
eric AT sandall.us                  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
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 all 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 all 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 all 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.
  - Exception to the above: Automatic Removal Votes (triggered by inactivity 
as
    specified in the Developer Organization document) automatically pass 
unless
    a simple (51%) majority vote against the removal.
- Successful or failed removal votes MAY be vetoed by the entire group of
  Developers.
- If an Automated Removal Vote fails fails, the Developer in question WILL be
  automatically nominated and seconded for a Removal Vote every six months 
they
  continue to be inactive.

Veto Process:
- The 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 MAY vote, but are not required to.
  - General Developers MAY cast a binding vote.
  - 51% of the Developers (Lead + 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: signature.asc
Description: OpenPGP digital signature