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