Short story: A Veto carries a lot of power [1], and it brings imbalance to a supposedly democratic process. For normal votes, especially those that ask for opinions, not for validation of a critical decision, a -1 should count as a normal vote. In this case, an actual Veto should be marked as such. Proposals:
A. Keep -1 as a Veto, but require the voter to really justify the veto with technical reasons. If the vetoer fails to convince other of his reasons, and the majority still agrees with the proposal, then the veto can be discarded, and the vote passes. B. Separate -1 from Veto. A -1, by default, counts just as a vote against the proposal, and the majority will rule. An actual Veto must be marked as such, but the vetoer must bring very good reasons for the veto. C. Just keep things as they are now, since you think that the current process has worked well so far, and nobody abused the right to veto. Long story: The right to Veto a VOTE means that just one participant can block a whole vote, even though the vast majority thinks otherwise. This is a very powerful right, and I for one tried to avoid using it as much as possible: in general I use -0 for solutions that I don't particularly like, but for which I don't have an actual better solution, or an universally acceptable reason that can convince everybody else of my decision. It makes sense to have the Veto power, as a way to spotlight serious problems with a proposal. The expected outcome in this situation is for the vote sender to understand and accept the outcome, and go back to redesigning the proposed solution, fixing the problems exposed. But when votes are just about opinions, and about choosing the version that most people like, it is hard to say that one opinion is more important than others and it can rightly prevent reaching a conclusion. This is particularly true about UI design and UX, but also about voting on processes and rules. One possible outcome is that votes (and the proposals being voted) get deadlocked, blocking progress. The rules say that the proponent should review and change the proposal and restart the vote. Sometimes the effort put into the original proposal is considered big enough, and if the vetoer failed to convince the proponent of the problems, there won't be any more work put into the proposal, and it will just die. I'm not saying that this happens too often, but it does from time to time, at least for me. So, I think that the Veto power should be used sparingly. I see two options: A. Keep -1 as a Veto, but require the voter to really justify the veto with technical reasons. Currently, the rules say that the vote sender must try to convince the vetoer about the rationale of the voted proposal. It should also be the other way around: if the majority agrees with the proposal, the vetoer should try to convince the others why the proposal is bad. If the vetoer fails to do that, and the majority still agrees with the proposal, then the veto can be discarded. B. Separate -1 from Veto. A -1, by default, counts just as a vote against, and the majority will rule. -1 keeps its power as a strong opinion against the proposal, and it should be justified and the voter should try to convince others why the proposal is bad. A -1 can still influence other voters and can change the outcome when the concerns raised in the motivation for the -1 are accepted as valid. We can put more weight into the -1, so for example a vote passes if (2*-1s) + (+1s) > 0, or (-1s) + (+1s) > 3, or another balanced variation. An actual Veto must be marked as such, but the vetoer must bring very good reasons for it. I'm +1 for either proposal, leaning towards 2, since it's clearer when a vote can be passed or not. To offer the other alternative: C. Just keep things as they are now, since you think that the current process has worked well so far, and nobody abused the right to veto. [1] http://dev.xwiki.org/xwiki/bin/Community/Committership#HVoting -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
