Berin Loritsch wrote:
From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
This document details how the Avalon PMC has agreed to handle voting.The above paragraph needs to be totally reviwed/replace/rehashed/removed?.
Should this document conflict with official ASF policy, please notify
[EMAIL PROTECTED] so that they can make the proper changes. ASF
policy will always supercede this document.
* 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.
Yep - I agree.
=== The Proposer ===It should be noted that a proposer may be any project committer.
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".
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.
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 ===This is not talking about PMC votes - its talking about
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".
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.).
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.Again, for the people, by the people. Of course that is my== Prior to the Vote ==Discussion on a proposal WILL take place. Discussion MAY take place on the Avalon dev list. Discussion MAY take place on the PMC list.
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.
American sensibilities coming out. Ever hear of taxation without
representation? We need to give the greater Avalon community
representation in these matters.
Does it really need to be explicitly stated? We have already been== The Vote ==Voting requires discussion - but readiness for adoption is vauge
When the proposal is ready to be adopted by the community, the
Proposer will call for a vote.
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.
told that the Chair has benevolent dictator rights for any
community.
I.e. there is no need to mention it.
Again, For the people, By the people.All votes occur on the AvalonVotes may be held on the PMC or Dev list - that up to whoever is
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.
initiating the vote and will reflect the content of the vote. Votes should be marked [PMC:VOTE]. See Leo's text.
Can you go up to congress and place a vote? No. Are you represente? Yes. Bad argument.
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.
Point taken. However I don't want us to be in the habitBecause a vote has already been discussed by the community,Disagree on requirement for a detailed explination.
the voter who expresses a vote of -1 is required to provide
a detailed explanation as to why the voter opposes the
subject.
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.
of simply throwing out -1 without an explanation--esp. when
it is warrented.
It should when there are two different types of voting.=== Types of Votes ===Procedures should not qualify types of votes. Thats' a matter for the PMC to cosider during discussion.
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.
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?
Umm, don't follow - ??
Right. Got the titles yet?==== Qualified Majority Vote ====The should be more clear. Botes relating to the modification
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.
of the "Avalon PMC Charter" or "Avalon PMC Policies and Procedures"
shall require a 2/3 majority. The above should refer to specific
documents.
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/
Committers need representation.==== Normal Majority Vote ====The mixing of committers and PMC members on voting confusses
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 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 passesDisagree - voters are PMC members - period.
with more than half (1/2) of the voters support, the PMC
members will ratify it.
Committers have represention though elected PMC members. Same things applies in the States .. ;-)
Umm - and we agree on what "representation" means? Representation != quorum.
Not everyone knows what "quorum" means. I am using laymans==== Duration ====I prefer using the correct words for this - its called "quorum".
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.
words for the laymans text.
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]>
