One of the strongest arguments that I've made
against voting is that
voting is usually game theoretically bad. I can explain what I mean
by that if anyone is interested, but basically I think that we can
find better solutions under a consensus-seeking incentive system than
a power-bloc-seeking incentive system.
My main argument against consensus is that we do not really use what I
would consider a consensus process. A consensus process, in my opinion, is
a process where you argue for some time, and eventually find a solution
that everyone at least is willing to tolerate. In reality, in most past
cases our process has been one where people come from very different
positions and never really arrive at what could be considered a compromise
pleasing to all (or even "nearly" all) parties -- we're just too large and
too different for that to work, and I wouldn't want it any other way.
So what happens -- as in the case of what we should do with Clutch, with
Lir, with TMC, as in recent NPOV discussions etc. -- is that usually Jimbo
weighs in after a while and the matter is settled, for a variety of
reasons which center around Jimbo's role in the project and the respect
people have for him. This is not really a consensus process -- it's a
discussion process with a benevolent dictator as the ultimate arbitrator
and decision maker. Jimbo says he only tries to quantify the "intensity"
of disagreement and whether a "nearly unanimous" consensus has been
reached, but it's not that mechanical, especially as there are no fixed
criteria for this. Once these are more and more precisely defined, the
system gets closer and closer to an actual voting system.
I think we all know that, too, but we like to uphold the "consensus"
picture because it pleases us more. Don't get me wrong, I'm not saying
this is necessarily bad (Linux is, after all, a benevolent dictator
project as well), just that it has its flaws, especially in the unlikely
case that Jimbo is wrong. It also has scalability problems.
The Debian project uses Concordet voting, BTW.
What I think we should do, and could do, is implement a basic voting
system in the Wikipedia engine that would allow people to create polls
(ideally offering different voting methods -- if you just have yes/no as
choices, first past the post seems fine). These could be used to collect
data informally in various situations, like the recent moderation debate.
They would NOT be accepted, by policy, as a way to assert that X or Y
should be done, just a method to tabulate/quantify opinions. People are
already doing this manually (votes for NPOV , votes for deletion, votes
for ..), and it seems difficult to argue that we shouldn't simplify
things.
I would be willing to work on that (could take a while, but I won't forget
it). Magnus has also expressed interest in this area.
We could then also have a formal process to use such polls as the basis of
actual decisions in cases where consensus seems unattainable (what Jimbo
chatacterized as the very few cases where voting might be necessary to
make a decision). The decision whether to use a poll for this purpose in
an individual case would rest with Jimbo.
That way we can explore the different options available carefully, without
imposing anything. There are certainly arguments that can be made for or
against either the consensus/BD or the voting process. What I think we
should resist is the temptation to avoid changing our process because of
fear of change itself. Wikis themselves are the result of an evolutionary
process, and this evolution shouldn't stop.
Regards,
Erik