24 Jan
2013
24 Jan
'13
12:26 a.m.
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