Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Project Organization Policy Vote

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Robin Cook <rcook AT wyrms.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Project Organization Policy Vote
  • Date: Wed, 26 Apr 2006 22:44:36 -0500

To me this is not a Team Lead vote only issue. This in a reorg vote and
should be a general vote.

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




Archive powered by MHonArc 2.6.24.

Top of Page