Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] second set of amendments to voting policy

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] second set of amendments to voting policy
  • Date: Sun, 9 Jul 2006 13:41:35 -0500

Now that we've been using these new voting policies for a few elections,
we've found a few issues they don't adequately address. I'd like to kick
off discussion of some amendments to fix these shortcomings. Some of these
are issues that we've run into during actual votes, some of them are issues
that have come up in IRC as people have been discussing things that would
need to be added to aid getting the non-profit going.

A clean diff against the current policy docs is attached. I'm also going
to list the changes here to give rationale behind them. We can discuss
them a bit here, then I'll make a motion to approve whatever comes out of
that discussion as the way to go.



- Change the inactivity limit for general developers from one year to six
months (after this they are automatically put up for a removal vote).
This was supposed to get changed before the initial proposal based on
feedback from various people, but didn't get changed. Changing this now
may be controversial but I'm putting it out there anyway so we can
discuss it.
- Fix a typo ("hold in that period" -> "held in that period").
- Define what the "Project Policy" is so it's clear what things are
eligible for veto votes.
- Set the Project Policy to supercede any other policies.
- Define a policy for resolving questions of interpretation (provide a way
to vote on these, and set the Project Lead as the final authority if a
vote can't resolve it).
- Clarify that a motion/vote/etc. is received when it is accepted by the
list server MTA.
- Allow changing of lead election votes up until the election ends.
- Allow withdrawing motions or seconds up until the vote starts.
- Clarify Leads need to always vote, even if a majority has already been
reached.
- Clarify veto votes are immune from the effects of whatever new motion
they are trying to veto.
- Rearrange some bullets.



Things not in this diff that we may want to add (these have had some
discussion already, but not as much consensus):
- A provision for changing votes on issue votes before the vote ends.
- More explicit language that issue votes can be used to decide things for
component leads who are absent.
- More explicit language around the authority of the project lead over
individual components.
diff -dup amend1/policy_developers amend2/policy_developers
--- amend1/policy_developers Tue Apr 18 11:35:40 2006
+++ amend2/policy_developers Sun Jul 9 13:03:05 2006
@@ -22,8 +22,8 @@ General Developrs:
- 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
+- 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).

Lead Developers:
@@ -38,7 +38,7 @@ 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.
+ held 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).
diff -dup amend1/policy_voting amend2/policy_voting
--- amend1/policy_voting Fri May 5 08:49:22 2006
+++ amend2/policy_voting Sun Jul 9 13:38:27 2006
@@ -9,11 +9,16 @@ 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 "Project Policy" is defined as the combination of the Developer
+ Organization document found at
+ http://www.sourcemage.org/DeveloperOrganization and this document, found at
+ http://www.sourcemage.org/VotingPolicy.
+- The Project Policy supercedes all other published or practiced Source Mage
+ policies.
+- A "Developer" is defined as 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)
@@ -24,9 +29,22 @@ General:
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.
+- If questions of interpretation of the Project Policy arise, any Developer
MAY
+ move that the relevant question(s) be put to a vote. If this motion is
+ seconded, any current votes WILL be immediately suspended and the
+ interpretation motion WILL proceed as an Issue Vote as described below. If
+ the interpretation motion carries (on initial vote or veto) any votes that
+ were suspended WILL continue or be started over as required by the result
of
+ the interpretation motion. If more than 50% of the Lead Developers move
that
+ a question of interpretation cannot be resolved with an Issue Vote, the
+ interpretation WILL be determined solely by the Project Lead without
+ possibility of veto.
- 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.
+- The Mailing List used for voting is sm-discuss AT lists.ibiblio.org.
+- A motion, vote, etc. reaches the Mailing List when it is accepted for
+ delivery by the mail exchanger for lists.ibiblio.org.

Lead Developer Votes:
- A General Developer MAY be nominated for Lead Developer at any time by any
@@ -79,6 +97,8 @@ 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 MAY be changed before the scheduled end of the vote by notification
to
+ the designated email address.
- 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.
@@ -111,13 +131,16 @@ Issue Voting Process:
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.
+- Motions or seconds MAY be withdrawn by the Developer that made them up
until
+ the time vote is called.
- 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.
+- Lead Developers MUST cast a vote before the scheduled end of the vote, even
+ if majority is reached early.
- General Developers MAY cast a vote, but their votes are advisory only
(i.e.,
non-binding).
- More than 50% of the Lead Developers MUST cast a vote, or the vote is
@@ -145,7 +168,7 @@ Developer Removal Voting Process:

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.
+ would modify the Project 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
@@ -157,4 +180,5 @@ Veto Process:
vote, or the veto is invalid and fails.
- Vetos require a super majority (greater than 2/3 of all votes cast) to
pass.
+- Issue Vote vetos are immune from the effects of the motion they apply to.
- Veto votes are final.

Attachment: pgpbnNX3bAZ5n.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page