Hi Sergiu and all, +1 for B with an amendment, for future reference lets call this option D.
"the vetoer must bring very good reasons for it" shall be clarified to: "Upon veto, the vetoer has opportunity to raise concerns and ask questions of those supporting the measure. Supporters of the measure have equal opportunity to ask questions of the vetoer. In either case, a reasonable question which goes unanswered for 72 hours after a 48 hour reminder is cause for dismissal or sustainment of a veto." The reasoning: Essentially what we are talking about is the filibuster, a tactic which nearly every legislative body has wrestled with at some point or another. This is a beneficial because it makes sure that any change of policy has at least consent, if not assent, of each committer. Unfortunately it also means that a committer can block a change even if the rest of the group is highly supportive. In a friendly group such as ours, the risk of malicious blocking is minimal but there are still some pathologies which we might find ourselves in. Sometimes a committer is worried about a change but does not have time to evaluate it properly, they might be tempted to -1 it so they can buy time to better understand it and then not find time to review it and form an opinion, in this way -1 is ``kicking the can'' and can happen innocently because of too much to do and poor planning. Another pathology which can grow from the filibuster is the development of a dictator who blocks anything which he doesn't like and uses liberal interpretation of the idea of "blocking without due supporting argument" to overturn others' vetos against ideas which he supports. I don't dislike the BDFL model, indeed some of the most successful projects use it, but they also place all responsibility for a release's quality on the shoulders of the BDFL. We don't do this so a highly influential committer is undesirable. Unfortunately a developer who takes charge tends to be revered and trusted in the community and other committers tend to agree without proper evaluation, making his elevation to dictator a self fulfilling prophecy. In order to counter the potential of both these pathologies while doing our best to preserve the benefits of the filibuster, I would like to give my +1 to option B. Furthermore I would like to propose refining the definition of "the vetoer must bring very good reasons for it" as explained above. A not so outrageous example of this would be a committer proposing a patch which is supposed to provide performance benefits at the cost of an API break. An objection might be raised to breaking API for unspecified benefits. The proposing committer would then be obliged to collect some performance benchmarks to support his position. Supposing the patch was shown to provide an across-the-board 30% performance gain and the vetoer maintained his position against, proponents of the measure could ask that the vetoer provide evidence that machines in the wild would be affected by the break in order to weigh the losses and the benefits. We're all reasonable folks so these measures are undoubtedly overkill but they provide us a nice framework so we don't end up discussing in circles a matter which can be resolved by application of process. Thanks, Caleb On 01/23/2013 01:53 PM, Sergiu Dumitriu wrote: > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
