avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: [PROPOSAL] PMC Voting Process
Date Tue, 21 Jan 2003 17:21:09 GMT
> 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?

> >=== 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.

> >=== 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".


> >== 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.

> >== 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.

> >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.


> >
> >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.

> >=== 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.

> >==== 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?

> >==== 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.

> >==== 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.



--
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