Skip to Content.
Sympa Menu

sm-discuss - Re: [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: Re: [SM-Discuss] second set of amendments to voting policy
  • Date: Sat, 15 Jul 2006 19:45:30 -0500

There's been no real discussion of this so far; please keep in mind that
once proposed and seconded as an actual amendment, all Leads will be
required to vote. If you have things you want to remove or add please say
so now.

On Jul 09, Jeremy Blosser [jblosser-smgl AT firinn.org] wrote:
> 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.




> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss

Attachment: pgpSh0mMTP8Ai.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page