Public SourceMage Discussion List

[Robin Cook <rcook AT wyrms.net>]

Should use the current voting procedures until the new ones are voted
on.

CuZnDragon
Robin Cook

On Wed, 2006-04-26 at 11:58 -0700, Eric Sandall wrote:
> Hello all,
> 
> As Jeremy Blosser (emrys) has requested a vote of the Team Leads if his
> proposal (attached) is seconded (it was, by David Kowis
> (dkowis/kittah)), we have here a vote. :)
> 
> I believe Jeremy (correct me if I'm wrong) would like this vote to
> follow the guidelines attached, which means:
> * All votes must be GPG signed by a valid key listed on
> http://www.sourcemage.org/keysigning
> * Only Team Leads have a binding vote
> * Other developers may post a vote, but it is advisory only
> * Votes go to the mailing list (sm-discuss) with a +1 (yes) ,+/-0
> (abstain) ,-1 (no)
> * At least 51% of the Leads must vote for the vote to be valid
> * At least 51% of the voting Leads must vote +1 for the issue to pass
> * Non-Leads may veto the process after the vote has finished
>   * At least 51% of all developers (Lead + General) must vote
>   * At least 67% of the voting  developers must vote +1 for the veto to pass
> 
> -sandalle
> 
> plain text document attachment (policy_developers)
> 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.
> plain text document attachment (policy_voting)
> 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.
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss

Attachment: signature.asc
Description: This is a digitally signed message part