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
