Leo Sutic wrote:
All,
I have made an attempt at incorporating the issues on which we have reached consensus into the document. Here's the updated text, followed by a list of outstanding issues. As always, any mistakes are unintentional - we'll go over this text until everyone is satisfied.
I haven't put this text into the Wiki. I managed to wipe out the history of the AvalonVotingProcedures node and that has made me a bit wary about using the Wiki for purposes like this.
I'm developing a similar love/hate relationship with the Wiki myself! Anyway - onto the text which is looking better.
-oOo-
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.
== 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".
=== 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).
=== 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.
== 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.
== 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.
=== 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
=== 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.
=== 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.
==== 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.
==== 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.
.
=== 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.
==== 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.
==== 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.
== 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.
== 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
-oOo-
OUTSTANDING ISSUES
In the text I have done some changes that we don't have consensus on, but that I believe are non-critical issues. The idea is to get trivial things solved quickly so we can spend time on the major issues. Please review, and if I did something stupid, just let me know and we'll roll back.
1. I cut the text at the top, removing the "contact [EMAIL PROTECTED]" part of it.
2. Regarding point 6 in my previous email:
[http://marc.theaimsgroup.com/?l=avalon-dev&m=104316998814380&w=2]
6. "Procedures should not qualify types of votes."
I don't get this - I'll go through Leo's text and see...
Point 6 could be resolved by changing the text:
"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."
to
"There are two classes of votes: a Qualified Majority Vote and a
Normal Majority Vote."
That is, cut any parts related to what the PMC may/may not vote on.
+1 I've reflected this suggestion on the above proposed revisions.
3. Regarding point 7 in my previous email:
[http://marc.theaimsgroup.com/?l=avalon-dev&m=104316998814380&w=2]
7. PMC votes are limited to changes in two documents - "Avalon PMC
Charter" or "Avalon PMC Policies and Procedures".
Point 7 could be resolved by changing the text:
"Any vote that affects the PMC charter, affects the rules that govern the PMC is a Qualified Majority Vote."
to
"Any vote that affects the texts 'Avalon PMC Charter' or 'Avalon PMC Policies and Procedures' is a Qualified Majority Vote."
See above proposal concerning the text - I think its consitent with what your suggesting but also captures the quorum value.
I also note that my point 7 was wrong - "PMC votes ..." should be "Qualified Majority Votes ...", which is what Stephen said in his email (but I incorrectly summarized). (Otherwise we're really reducing the power of the PMC.)
4. I replaced "representation" with "quorum". Motivation: It is the proper term, and I found no really good synonyms. Plus, it is defined fairly well and should be graspable.
I have a bunch of code dealing with voting. Its actually an essential ingridient to collaborative component management in a distributed environment - but I'm difting - sufice to say that everyone should get a good grip on the defition of quorum.
Example: http://www.osm.net/doc/collaboration/org/omg/CollaborationFramework/VoteCeiling.html
5. I replaced [VOTE] with [PMC:VOTE] and [VOTE-RESULT] with [PMC:VOTE-RESULT].
+1
---------------------------------------------
Stephen, the changes should address points 1-5 in our previous exchange, and leave 6 and 7 (points 2 and 3 above in this email).
The suggestions I've put foward above are based on the feedback on the list - focussing maily on getting the statement somewhat more clear - and elimiating information where it is already defined. If the suggestions are go beyond your understanding on quasi consencus fell free to revise as appropriate.
Looking forward to the next iteration.
Keep up the excellent work - Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
