Re: Voting rules (was: RE: cvs commit: jakarta-ant/lib - New directory)

[Peter Donald <do...@apache.org>]

At 04:57  29/11/00 +0100, you wrote:
>When the vetoer becomes convinced that his reasons have been
>invalidated by the requesters counter-arguments, he can
>easily change his vote to 0 or +1, so there is no need
>for an 'automatic' change of the vote.

Well the problem occurs when someone will not argue their position and give
reasons for their convictions. If they don't do that then it is impossible
for the requester to respond to problems because they are not aware of them.

>So the interesting question is: what happens if the vetoer 
>is not convinced by the requesters counter-arguments? 
>Who should decide if the counter-arguments *really* have 
>addressed all issues? 
>
>This question has four possible answers:
>- the process continues without decision

one way.

>- a third party decides
>- the requesters position wins
>- the vetoers position wins

the other way.

>Letting the process continue means a de facto rejection
>of the change (if the vetoer doesn't change his mind), 
>because the requester can't proceed to commit the change 
>(I assume that the voting process takes place before the 
>change is done). 

depends - it is a lazy veto because it occured after the fact.

>That means that the first answer leads 
>to the same result as the last: the vetoer wins.

right.

>Your position seems to be a combination of answer one and 
>three: as long as the vetoer responds, the process 
>continues; if he stops responding, the requester wins. 

If the vetoer has all his problems solved by counters of requester and the
vetoer does not come up with new reasons to -1 then he is -1 without an
explanation (which is invalid).

>So there is only one choice left:
>the vetoer wins. Only the vetoer can recast his vote if he 
>becomes convinced by requesters counter-arguments. Otherwise 
>the change remains rejected.

right.

>Now let's take a look at the idea to put an obligation
>to answer on the vetoer. It doesn't really help the 
>requester to put such an obligation into the rules, 
>because a good will vetoer will always listen to the 
>requester's arguments while a bad will vetoer will 
>always produce some answer to comply with the rule.
>
>Another disadvantage is that the requester could try 
>producing more and more reasons, until the vetoer becomes 
>too tired to respond.


>(after rereading this paragraph I'd like to emphasize that I 
>don't think this is happening in the jar file discussion).
>My last argument against such an obligation is that it
>would have to become a very complicated rule to be
>fair to both parties (how many days may the vetoer wait 
>until he responds, what happens if he gets on holiday, ...).

;) You should see some of the discussions on other lists. Ant is relatively
tame - it took me about 3 months at one time to convince the other
committers not to veto something (and I needed to convinve them all as
their was only 3 other active committers). 

Depends on the group. Some of them (Cocoon and Avalon in particular) tend
to do things the "right" way and 

>Note that this is trying to be a theoretical discussion of 
>the rules. I don't have any opinion on the jar file issue.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*