avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [PROPOSAL] PMC Voting Process
Date Tue, 21 Jan 2003 18:57:56 GMT


Berin Loritsch wrote:

>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>    
>>
>>>This document details how the Avalon PMC has agreed to handle voting.
>>>Should this document conflict with official ASF policy, please notify
>>>pmc@avalon.apache.org so that they can make the proper changes.  ASF
>>>policy will always supercede this document.
>>>
>>>      
>>>
>>The above paragraph needs to be totally 
>>reviwed/replace/rehashed/removed?.
>>
>>   * the Avalon PMC procures are definative
>>   * in the case of any ambiguity or conflict, it becomes an
>>     issue for the chair
>>   * in the case of dispute between a committer and the PMC, the
>>     committer can address the problem to the chair or escalate
>>     the matter to the board
>>    
>>
>
>Got an alternative?
>

Chair decision is final.

>
>  
>
>>>=== 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".
>>>
>>>      
>>>
>>It should be noted that a proposer may be any project committer.
>>    
>>
>
>Does it really need to be a committer?  What about someone who is
>contributing but has not become a committer yet?  The origin of a
>proposal doesn't really matter.  We decide if it is valid, or
>something that needs to be addressed later.  That can be communicated
>before a vote is issued.
>

Yep - I agree.
I can't really imagine why a non-committer would want to raise a 
discussion/vote on the PMC - but yep - it could be anyone.

>
>  
>
>>>=== The Voter ===
>>>
>>>A voter is someone who expresses support or opposition for the
>>>subject being voted on.  For a voter's vote to count, he must
>>>be qualified.  All voters must either be a committer on the
>>>Avalon project or an Avalon PMC member.  Certain types of votes
>>>require that the voter be a PMC member.  The different types of
>>>votes are detailed in the section "The Vote".
>>>
>>>      
>>>
>>This is not talking about PMC votes - its talking about
>>voting in general.  Leo's version ono this is much more
>>specific and appropriate. PMC votes do not require
>>qualification. Voters are PMC members - nobody else.
>>    
>>
>
>Again, I want the greater Avalon community to be able to be involved
>with the process by which it is governed.  By only allowing the
>PMC to vote on issues almost fosters an attitude of "why bother the
>general list, we can take care of it behind the scenes and noone
>will have to know".
>

I think you and I have different ideas about what the PMC will be
dealing with. Once we are over and done with the policies - the PMC
activities will probably drop to reporting to the board related stuff.
The sort of things that may be dealt with in the future concern
conflicts - conflicts from the board to us about something - or
conflicts someone has with Avalon that they feel they cannot resolve
in public (or do not whish to resolve in public).

Once PMC member voting procures are out of the way we will still need
procedures for community general voting (which will hopefully come from
incubator).  These are the operational procedures.  PMC procedures are
the handle cases whee operation stuff breaks down (e.g. veto contesting,
etc.).


>>>== 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, 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.
>>>
>>>      
>>>
>>Discussion on a proposal WILL take place.  Discussion MAY 
>>take place on the Avalon dev list.  Discussion MAY take place 
>>on the PMC list.
>>    
>>
>
>Again, for the people, by the people.  Of course that is my
>American sensibilities coming out.  Ever hear of taxation without
>representation?  We need to give the greater Avalon community
>representation in these matters.
>  
>

In what matters - the last tiime I received a request from a PMC I can 
assure you that I wanted that to proceed in private - i.e. I was 
communicating with the PMC and only the PMC.  I repeat - PMC member 
procerures are dealing with different things to operational procedures.  

>>>== The Vote ==
>>>
>>>When the proposal is ready to be adopted by the community, the
>>>Proposer will call for a vote.  
>>>
>>>      
>>>
>>Voting requires discussion - but readiness for adoption is vauge
>>and missleading.  If the chair deems that further discussion is
>>required before moving to a vote, the chair should be able to
>>revert a vote to discussion.
>>    
>>
>
>Does it really need to be explicitly stated?  We have already been
>told that the Chair has benevolent dictator rights for any
>community.
>  
>

I.e. there is no need to mention it.

>  
>
>>>All votes occur on the Avalon
>>>developers mailing list, andhave the text "[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.
>>>
>>>      
>>>
>>Votes may be held on the PMC or Dev list - that up to whoever is
>>initiating the vote and will reflect the content of the vote.  
>>Votes should be marked [PMC:VOTE]. See Leo's text.
>>    
>>
>
>Again, For the people, By the people.
>
>  
>

Can you go up to congress and place a vote? No.
Are you represente? Yes.
Bad argument.

>  
>
>>>Because a vote has already been discussed by the community,
>>>the voter who expresses a vote of -1 is required to provide
>>>a detailed explanation as to why the voter opposes the
>>>subject.  
>>>
>>>      
>>>
>>Disagree on requirement for a detailed explination.
>>This is required on things like vetos but it is not required
>>on a majority vote.  Voters (PMC members) should not be required
>>to explain their voting position.
>>    
>>
>
>Point taken.  However I don't want us to be in the habit
>of simply throwing out -1 without an explanation--esp. when
>it is warrented.
>  
>

I agree - but I think is much more something for the operation 
procedures applicable to committers.  At the operation level we should 
encorage explinations of -1 on concensus voting (but not require them). 
 The story is totally differnet for veto votes - but as you can see - 
this is a seperate subject.

>  
>
>>>=== 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.
>>>
>>>      
>>>
>>Procedures should not qualify types of votes.  
>>Thats' a matter for the PMC to cosider during discussion.
>>    
>>
>
>It should when there are two different types of voting.
>Either we have all one type of voting or we declare what
>subjects go under which type of voting.
>  
>

I confussed - we are talking about PMC voting procedures.  The only
"types" of voting is majority or qualified majority.  This has nothing
to do with the subject of the proposal/vote.  Perhaps you reference to
"type" is different to the current procedures?

>  
>
>>>==== 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 a two-thirds (2/3) majority of
>>>voters who are PMC members.  Input is appreciated from
>>>committers and all other members of the community, but only
>>>votes from PMC members are counted for this type of vote.
>>>
>>>      
>>>
>>The should be more clear.  Botes relating to the modification
>>of the "Avalon PMC Charter" or "Avalon PMC Policies and Procedures"
>>shall require a 2/3 majority.  The above should refer to specific
>>documents.
>>    
>>
>
>Right.  Got the titles yet?
>  
>

Umm, don't follow - ??
we have a very brief charter established by the board and a set of 
proceures.
http://cvs.apache.org/viewcvs/jakarta-avalon-site/docs/pmc/

>  
>
>>>==== Normal Majority Vote ====
>>>
>>>All votes that do not fall under the heading of Qualified
>>>Majority Vote are handled as a Normal Majority Vote.
>>>Examples of PMC actions that fall under this heading include
>>>creating new CVS repositories, or creating or merging mailing
>>>lists, but it is not limited to just those activities.
>>>All committers will vote on the subject, 
>>>
>>>      
>>>
>>The mixing of committers and PMC members on voting confusses
>>the issue/procedures.  Certainly - if a PMC matter is being
>>discussed and voted on the dev list - a commiter can comment.  
>>But a committer cannot vote - ok - they could send an email
>>with something that looks like a +1 or a -1 but its not a vote
>>and should not be referenced as such - its an opinion.  This
>>simply confuses the procedures.  It is better to drop this
>>notion completely - if a vote is held on the dev list then
>>we are implying that comment is encoraged (otherwise the vote
>>would have been held on the PMC list).  Procedures do not need
>>to talk about non-voter votes because they simply don't exist.
>>
>>    
>>
>>>and if it passes
>>>with more than half (1/2) of the voters support, the PMC
>>>members will ratify it.  
>>>
>>>      
>>>
>>Disagree - voters are PMC members - period.
>>    
>>
>
>Committers need representation.
>  
>

Committers have represention though elected PMC members.
Same things applies in the States .. ;-)

>  
>
>>>==== Duration ====
>>>
>>>All votes will last for at least a week.  If there is
>>>not enough representation 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 proper representation
>>>is available.
>>>
>>>      
>>>
>>I prefer using the correct words for this - its called "quorum".
>>    
>>
>
>Not everyone knows what "quorum" means.  I am using laymans
>words for the laymans text.
>  
>

Umm - and we agree on what "representation" means?  
Representation != quorum.

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message