Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] Full vote for Organization Policy

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: [SM-Discuss] Full vote for Organization Policy
  • Date: Thu, 27 Apr 2006 13:05:22 -0700

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



  • [SM-Discuss] Full vote for Organization Policy, Eric Sandall, 04/27/2006

Archive powered by MHonArc 2.6.24.

Top of Page