Stephen, some quick comments and questions:
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>
> Leo Sutic wrote:
> >
> > PROPOSAL TEXT
> >
> > = PMC Voting Procedures =
> >
> > This document details how the Avalon PMC has agreed to
> handle voting.
> > ASF policy will always supercede this document.
>
>
> Suggested replacement text:
>
> This document is revision 2 of the adopted Avalon PMC Policies
> and Procedures. It established the rules under which the project
> operations and it maintained by the PMC.
>
> General comment: The notion of ASF always superceding the Avalon PMC
> procedures is backwards. In fact the reality is that the Avalon PMC
> procedures extend and or qualify ASF procedures.
OK, sounds good to me. As you say, the current formulation is a bit
backward.
> >
> >
> > == People Involved in the Voting Process ==
> >
> > === The Proposer ===
> >
> > The proposer is the one who comes up with the discussion
> that needs to
> > be addressed. The proposer will follow the procedures listed under
> > the heading "Prior to the Vote".
>
>
> Suggested replacement text (simplification of wording):
>
> Any member of the Avalon community may initiate a proposal to
> the Avalon PMC.When initiating discussion on a PMC matter, the
> member shall follow the procedures refered to under the heading
> "Prior to the Vote".
[Waiting a bit with this one. See below.]
> >
> >
> > === The Vote Administrator ===
> >
> > The vote administrator is the person who tallies the votes
> and reports
> > the results back to the developer list. The person who
> actually puts
> > a proposal up for vote is usually the vote administrator, although
> > this task can be taken on by someone else.
>
>
> Suggested improvement (simplification and clarification of text):
>
> The vote administrator is normally a PMC Member initiating a
> vote on a particular resolution. The vote administrator normally
> tallies vote results and reports the results back to the
> appropriate mailing list (Avalon PMC list or Avalon developer
> list).
[Waiting a bit with this one. See below.]
> >
> >
> > === The Voter ===
> >
> > A voter is someone who expresses support or opposition for
> the subject
> > being voted on. A voter must be an Avalon PMC member. Input is
> > appreciated from committers and all other members of the community,
> > but only votes from PMC members are counted.
>
>
> Suggested improvement (simplification and clarification of text):
>
> A voter is a PMC member expressing support, opposition or
> abstantion on a particular proposal.
>
> Comment: Input from comitters should be encoraged during the
> disucssion
> phase, not the vote phase.
[Waiting a bit with this one. See below.]
> >
> > == Prior to the Vote ==
> >
> > Before any vote can take place, the subject must be
> discussed with the
> > larger Avalon development community. All such discussions
> take place
> > on the Avalon developer mailing list or the Avalon PMC
> mailing list,
> > and have the text "[PROPOSAL]" in the subject line. That practice
> > alerts the developers to the fact that you eventually
> intend to call a
> > vote on the subject.
>
>
> Suggested improvement (simplification and clarification of text):
>
> Before initiation of a vote, discussion shall take place
> on either the Avalon development or PMC list. Proposal
> shall be sigifed as such via inclusion of the test "[PROPOSAL]"
> in the message subject. This practice alerts member to the fact
> that you eventually intend to call a vote on the subject.
>
> Comment: It is not a requirement for votes to be disucssed in
> the "larger
> Avalon Community" and as such I dropped the phrase.
[Waiting a bit with this one. See below.]
> >
> >
> > == The Vote ==
> >
> > When the proposal is ready to be adopted by the community, the
> > Proposer will call for a vote. All votes occur on the Avalon
> > developers mailing list or on the Avalon PMC mailing list, and have
> > the text "[PMC:VOTE]" in the subject line. That practice
> alerts the
> > developers to the fact that the prior proposal is now ready to vote
> > on, and discussion should stop for the proposal.
>
>
>
> Suggested improvement (simplification and clarification of text):
>
> Once discussion on a subject has concluded, a member of the PMC
> may initiate a vote under the PMC or developer list. A vote is
> initiated under a email message with a subject commecing with
> "[PMC:VOTE]". That practice alerts members to the fact that the
> prior proposal has moved to the voting stage and that discussion
> has terminated.
[Waiting a bit with this one. See below.]
> >
> >
> > === How to Vote ===
> >
> > The voter responds to the original call for vote with an
> expression of
> > support, opposition, or abstention. The exact way to express the
> > voter's position is listed below:
> >
> > * +1 a vote supporting the subject
> > * +0 a vote abstaining from the subject, but showing some support.
> > * -0 a vote abstaining from the subject, but showing disapproval.
> > * -1 a vote opposing the subject
>
>
> Suggested improvement (simplification and clarification of text):
>
> A member of the PMC may register a vote in support, opposition or
> abstention in accordance with the following protocol:
>
> * +1 a vote supporting the resolution
> * +0 a vote of positivate abstaintion
> * -0 a vote of negative abstaintion
> * -1 a vote opposing the resolution
[Waiting a bit with this one. See below.]
> >
> >
> > === Counting Votes ===
> >
> > The vote administrator will count only the last vote from
> each voter.
> > That means a voter may change their vote at any time during the
> > duration of the vote. It is the vote administrator's duty to make
> > sure that the voter is qualified to make a vote on the
> subject. The
> > qualifications are listed under the sub heading "Types of Votes".
>
>
> Suggested improvement (simplification and clarification of text):
>
> The last vote sumbitted by a PMC member on close of the
> vote shall stand as the voters position on the resolution.
>
> Comment: The rest has already been covered and does not need to
> be restated.
[Waiting a bit with this one. See below.]
> >
> >
> > === Types of Votes ===
> >
> > The PMC may vote on any number of procedures. It is not the PMC's
> > role to affect the technical direction of the Avalon
> project, but its
> > procedural direction. There are two classes of votes: a Qualified
> > Majority Vote and a
> > Normal Majority Vote.
>
>
> Suggested improvement (following suggested text):
>
> There are two classes of votes: a Qualified Majority Vote
> and a Normal Majority Vote.
Sounds fine.
> > ==== Qualified Majority Vote ====
> >
> > Any vote that affects the PMC charter, affects the rules
> that govern
> > the PMC is a Qualified Majority Vote. For this type of
> vote to pass,
> > it requires support from two-thirds (2/3) of the voters.
>
>
> Suggested improvement (following suggested text):
>
> A Qualified Majority Vote vote concerns changes in two
> documents - "Avalon PMC Charter" or "Avalon PMC Policies
> and Procedures". A Qualified Majority Vote requires a
> quorum of at least 3 votes, or, at least votes from at
> least (2/3) of the PMC membership - whichever is the
> higher.
It is my understanding that quorum is 50%, irrespective of the type
of vote:
(b) Quorum Calculations
Quorum on all motions shall be at least three (3) and not
less than 50% of the elected members (rounded up to the
nearest non-fractional number).
...
(e) Qualified Majority Vote
A vote undertaken within the scope of a Qualified Vote as
defined by definition [5], meeting preconditions defined under
Article 1 (a), shall require a majority of greater than 2/3,
shall be subject to the quorum calculations as defined under
Article 1 (b), and vote duration as defined by Article 1 (f).
I think your paragraph describes something different here.
> > ==== Normal Majority Vote ====
> >
> > All votes that do not fall under the heading of Qualified Majority
> > Vote are handled as a Normal Majority Vote. If it passes
> the PMC vote
> > with more than half (1/2) of voters supporting it, then the
> vote has
> > passed.
> >
>
> Suggested improvement:
>
> A Normal Vote is any vote outside of the scope of a Qualified
> Majority Vote. A Normal Majority Vote requires a quorum of at
> least 3 votes, or, at least votes from at least (1/2) of the
> PMC membership - whichever is the higher.
Same as the Qualified Majority Vote paragraph - quorum is 3 voters
or 50% of PMC, whichever is highest. But to *pass* a Qualified Majority
Vote requires *support* from 2/3 of voters, while a Normal Majority
Vote only requires support from 1/2.
> > .
> >
> >
> > === Voting Qualifications ===
> >
> > In order for any vote to be considered binding it must have quorum,
> > and be held for the proper amount of time.
>
>
> I don't think this is needed as it is stated under the
> respective quorum
> statement and vote duration statement.
[Waiting a bit with this one. See below.]
> >
> >
> > ==== Quorum ====
> >
> > For all votes, there must be at least three (3) voters and
> half (1/2)
> > of the PMC must cast a vote.
>
> No longer required irelative to above proposed text.
I disagree...
> >
> >
> > ==== Duration ====
> >
> > All votes will last for at least a week. If there is not quorum
> > within the first week, then the length of time will be extended for
> > one additional week. If the vote still does not have
> enough support,
> > then the vote is considered failed. The proposer can
> choose to bring
> > it up later when quorum is available.
>
>
> Suggested improvement (simplification and clarity):
>
> A voting process thall remain open for an inital period
> of 7 days. If quorum is established within the period the
> vote shall be consider closed. If quorum has not been
> achieved, the voting process shall continue for an addition
> 7 days following which the process shall close definitavely.
> If at the end of 14 days the vote has not established quroum
> based on the number of votes registered, the vote shall be
> considered as failed.
[Waiting a bit with this one. See below.]
> >
> > == After the Vote ==
> >
> > When the vote is closed, the results of the vote are
> summarized by the
> > Vote Administrator. The vote administrator will send an
> email to the
> > Avalon
> > developer's list with the text "[PMC:VOTE-RESULT]" in the
> subject that
> > has the summary. The summary will include the count of all +1, +0,
> > -0, and -1 responses, and the final verdict of whether the subject
> > passed.
>
>
> Suggested improvement (simplification and clarity):
>
> On conclusion of a voting process, the vote admistrator
> may forward a notification of the vote result to the
> appropriate mailing list under the subject
> "[PMC:VOTE-RESULT]". The vote result should include a
> summary of the supporting, opposing and absention votes
> registered in the process and the result of the vote.
[Waiting a bit with this one. See below.]
> >
> >
> > == Disagreements ==
> >
> > Disagreements concerning voting may be directed to the Chair. The
> > Chair's opinion shall be final and binding upon the PMC.
>
>
> +1
>
> >
> >
> > END PROPOSAL TEXT
> >
>
> Looking forward to the next iteration.
I'm holding off a bit waiting for comments from Berin / Leo Simons /
anyone else.
Basically, your changes that fix mistakes and the ones that were
related to the points I listed are fine. The changes that are
merely stylistic I'd like to hold back for a little while - I
don't want us to try to find the most beautiful text for this
proposal. That said, I think at least some of your changes do
clean things up.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
