Voting rules (was: RE: cvs commit: jakarta-ant/lib - New director y)

["Siberski, Wolf" <Wo...@tui.de>]

Sorry for jumping into this discussion as a
non-committer, but I couldn't resist.

Peter Donald wrote:
> [Sam Ruby wrote:]
> >Peter Donald wrote:
> >>
> >>> Nevertheless, if I had voted -1, as Sam has done,
> >>> I hope it would not just degrade to -0. That isn't
> >>> how I understand the decision making process.
> >>
> >> Well you can't -1 with no reason. I think I have
> >> tried to address all the reasons (at least that I
> >> aware of ;]) for -1 so the -1's effectively become
> >> +0s unless more reasons are supplied ;). I don't
> >> know if thats official but thats the way it seems
> >> to occur in the groups I monitor ...
> >
> >Very dangerous.  Concrete example: suppose somebody decided they really
> >wanted to make Ant functionally equivalent to make.  Suppose they believe
> >that they had addressed to their own satisfaction any and all concerns,
and
> >therefore all vetos were mere nuisances. 
> 
> It is not about addressing the issue to my satisfaction - it is about
> solving the problem. If the problem no longer exists then how can it be
> said to not be addressed to anyones satisfaction? If the solution is
> non-optimal, wrong, whatever then more problems will be raised with that
> and the process will continue.

That is true, but IMHO You put the burden of proof on the wrong 
side.
For the discussion I'll call the vetoing committer the 'vetoer'
and the person requesting a change the 'requester'
(that's probably ugly english, but makes the text more 
understandable).

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.

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
- a third party decides
- the requesters position wins
- the vetoers position wins

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). That means that the first answer leads 
to the same result as the last: the vetoer wins.

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. 
I'll address the obligation to respond below.

There seems to be no third party who could play judge here, 
so the last two answers remain.

Let's take a look at the third option:
IMHO the vetoing mechanism was invented to let only changes
pass on which all committers (more or less) agree. 
Additionally, if we let the requester win, the vetoer could 
propose to undo the changes, and, as he is now in the 
requester position, would win this time, so the process has 
no defined end.
That rules out the third answer, too.

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.

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

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

Wolf

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

[Stefan Bodewig <bo...@apache.org>]

Wolf Siberski <Wo...@tui.de> wrote:

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

Thank you, Wolf. My aim was to discuss it on this abstract level,
that's why I changed the subject in the first place.

I've seen the same dilemma that you describe - and couldn't come up
with another conclusion but "the vetoer wins" either.

Stefan