RE: PMC Voting Process

[Leo Sutic]

All,

I'd like to briefly summarize what has been said so far, and suggest a way of moving forward. I know that this is a weekend, and that many may not even have seen the first post I made on this subject (as it was done late Friday evening), but I think that judging by the replies I did receive, there is enough for at least a summary and a tentative suggestion on how to move forward.

-oOo-

THE TEXTS

Leo Simons:
http://marc.theaimsgroup.com/?l=avalon-dev&m=104270697629068&w=2

Berin:
http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonPMCVotingProcedures

Stephen:
http://jakarta.apache.org/avalon/pmc/PMC-VOTING-PROCEDURES.txt

-oOo-

BRIEF SUMMARY

There appears to be consensus that the different texts describe the same procedure - with the exception of how disagreements are resolved. There is also consensus that the process they describe (for the use case where there aren't any disagreements), is acceptable.

-oOo-

SUGGESTION FOR MOVING FORWARD

We appear to have two issues to solve:

1. The style of writing (strict / layman).

2. How to handle disagreements.

The impression I get is that point (2) is the most important one. That is, while the goal of the layman version is precisely to deliver a text in a certain style, the goal of the strict version is not to deliver a text in a strict format, but rather to address point (2).

Thus, I would like to put forward the following suggestion:

1. We start from Berin's proposal. To my eyes at least, it seems to be a middle ground between strictness and layman-ness. I think we may have to firm up some parts of it in order to cover some common use cases, and de-formalize some parts to make it more accessible, but it would seem to be a good starting point.

2. An explicit statement that any disagreements are arbitrated by the PMC Chair. Not just vote counts, but *everything*. As Greg Stein says, the PMC Chair can act on behalf of the ASF:

"If the PMC (and more precisely, the Chair) makes a decision,
then it is DONE. The Chair has full authority to act on behalf
of the ASF within the guidelines that the Board has provided to
that person."
- http://marc.theaimsgroup.com/?l=avalon-dev&m=104285006706268&w=2

The assumption here is that the Chair is "sane", and I think that is implied by the Chair selection process (i.e. since everyone votes, the Chair should end up being someone that the PMC trusts).

This would contain the fallback to Avalon.

Stephen, I'd like to ask you: Would this be an acceptable substitution? That is, replacing the mathod of solving disagreements by reading the text with human arbitration? This would enable us to un-strict the text a bit, and cut down on the detail level.

-oOo-

If the two points above are accepted, I would like to move forward by:

1. Comparing the three texts and ensure that we're really describing what we think we're describing (i.e. no contradictions, common use cases covered). This step will merge the three texts into one.

2. Add the provision that the PMC Chair will arbitrate any disagreements.

3. Then we go over the text until it is acceptable by everyone.

4. Switch to [PROPOSAL].

5. Get consensus, switch to [VOTE].

6. Vote the text through.

At this point I'd like to put the emphasis on "acceptable" as opposed to "optimal". As there is always somehing that can be improved, I'd rather we reached a point where everyone can *accept* the text and then voted it through, than wait until we have the *optimal* text. This way, we can deal with the 10% we don't have consensus on separately from the 90% we do have it on - and more importantly, make the 90% we do have consensus on official.

7. Follow up on issues that were deemed non-critical that we have postponed. For example, a better formulation of a paragraph that doesn't change its meaning, indentation style, etc...

8. Make a [PROPOSAL] of (7).

9. [VOTE] on (8).

/LS


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>