[xwiki-devs] [VOTE] Separate the power of Veto from -1 votes
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
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
Hi Sergiu, On Jan 23, 2013, at 7:53 PM, Sergiu Dumitriu <[email protected]> wrote:
Short story:
A Veto carries a lot of power [1], and it brings imbalance to a supposedly democratic process.
it's not supposed to be democratic btw, but meritocratic ;)
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:
Before going further down, you've not explained what is wrong and where you've seen issues. There's no point in changing something that works so you should start by stating the problem.
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.
I don't like this. One reason I think our current Veto rule is good is because it allows people outside XWiki SAS for ex to have power to stop things. Imagine that the XWiki SAS company wants to push for some marketing stuff that is not in the best interest of the project, since it has a majority of committers who are XWiki SAS employees it means it can get its stuff in all the time.
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.
Using -1 is already saying that you're vetoing the change. If you don't like the change but still want to let it go you vote +0 or -0. I don't feel we need to change that
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.
Yes I don't remember an instance of abuse and I think it's working quite well. The only place where we didn't succeed in progressing is the new logo but I doubt that any other rules would have resulted in a good solution either ;)
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.
Yes that's the spirit :)
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.
I think this email shouldn't be sent as a VOTE because it's actually asking for opinions. It would better as a Discussion or Brainstorming. And once we look at all solutions and have finished the discussion then we could send a VOTE to propose 1 solution only and not N. You won't be able to close this VOTE because people can say they don't agree with one proposal (-1 for ex) and agree with others. This is why this email shouldn't be a VOTE. In general VOTEs that propose N solutions should be avoided and instead sent as proposal, discussion or brainstorming. Note: I made a mistake in replying to your previous VOTE email saying that this email was legit as a VOTE email. I hadn't read it at that point.
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 for C unless someone shows me several examples of things that are going wrong because of the veto rule and that we cannot satisfactorily resolve. If the outcome is that from 100 VOTes there's 1 that couldn't be satisfactorily resolved then I don't think it's a good reason enough to justify a change. IMO reminding people how to VOTE and explaining the power of VETO and how a VETO should be explained would be enough in this case. Thanks -Vincent
[1] http://dev.xwiki.org/xwiki/bin/Community/Committership#HVoting -- Sergiu Dumitriu http://purl.org/net/sergiu
On Wed, Jan 23, 2013 at 8:53 PM, Sergiu Dumitriu <[email protected]> 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.
IMO this separation is already done by '-0' and '-1'. I've seen that in [1] we don't mention what '-0' means but we've used a lot in the past and you explained it very well in an example below. Also from what I remember, every time someone votes '-' he explained why he did that. True that maybe we used more '-1' instead of using '-0' but we could change this by explaining their purpose more.
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.
I don't have any problems with the way we held our votes until now, but I didn't submitted many votes.
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.
The balance might work if we were much more committers. Right now if a vote has 8+ voters is a popular vote (usually we have 5 people voting). In a 5 people's vote, having a -1 states that there is a 20% disagreement. IMO that's a lot. So I think that '+1', '+0', '-0', '-1' works very well for us and we should just update the documentation to explain it better. Thanks, Caty
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
participants (4)
-
Caleb James DeLisle -
Ecaterina Moraru (Valica) -
Sergiu Dumitriu -
Vincent Massol