A Digg type tool can solve Wikipedia’s problems, written by Rod Boothby, proposes an interesting method for Wikipedia’s quality control: digg.com style vote. Of course you can say it won’t work because an article will be edited during the vote, but he claims degrading its vote result for each edit will solve the problem. I’m not certain if it works. It’s not easy to implement the degrading function. It seems suitable for Wikipedia 1.0 Stable Release Jimbo is planning, however. It will be suffice for release quality control to freeze edit and make a vote for each release candidate article.
Anyway, I’m very interested in how to sublate wiki-style and vote-style. Wiki is suitable for information gathering but not for decision making.
December 12th, 2005 at 7:18
I’ve written a post about that details this proposed voting system for Wikipedia. The post includes an example of the system implemented in an Excel spreadsheet.
Here are the key features:
I think the last point might be the most useful when it comes to implementing this system for Wikipedia.
As a comment to listing of the article on Digg, one person asked if this would help with low traffic pages. The voting system would not help tremendously here, but maybe, by recording a total of the people who have voted their opinion of the accuracy of the page, the voting system would also prove useful for low traffic pages. If a page had only 5 votes and a 80% confidence rating, that might not be viewed with as much certainty as a page with 1,000 votes and the same 80% confidence rating. Regardless, by providing the readers with full information, they can make up their own minds.
December 12th, 2005 at 20:57
Hmmm, it looks quite interesting.
Perhaps it’s important to decide proper degree of degrade for each edit, and perhaps we need several field trials. I’m now wondering how we can implement it into mediawiki.
December 13th, 2005 at 1:03
I have no idea what the right degrade level is.
You are right that it will probably require a few trials, and that the degrade is something the community will have to settle on as a whole. I thought about having degrade be driven by some kind of percentage change in the number of letters or links in the article, but then realized that even the addition of one word could radically alter meaning.
Degrade is one part of the algorithm that is “path dependent”. In other words, if you wanted to give people the option of selecting their own degrade level, you would have to sort a complete history of edit occurrences. The votes could be summed between edits. Compared with the amount of data that is actually stored in a wiki, this is pretty minor so maybe storing a full history isn’t a big deal.
December 16th, 2005 at 11:06
[...] 1と2は想定の範囲内だが、3には少し驚いた。まず Open Source Software の世界では fork を嫌う人も多い。そして Wiki というプラットフォームは、少なくとも私の観点からすれば、Fork に全く向いていないと思えるのだ。「最新版」が常に一つだけ存在し、全員がそれに対して追加修正を行なう、という方法によって Wiki は機能している。Fork できるなら Edit War も Fork で解決すれば良い話なのだが、そうすると Fork した後のそれぞれの版について別個に追加修正しなければならなくなり、手間がかかりすぎる。Right to Fork を GFDL の critical attribute だと言うなら話はわかるが、少なくとも現行の Wiki についてはそのように言えまい。 しかしそこから考えたのだが、Fork をサポートするような Wiki, つまり Fork した各版をうまく共通管理し、Fork 後のメンテナンスにも手間がかからないよう上手な仕組を入れ込んだ Wiki というのは作れないだろうか。これにさらに digg.com のような投票方式を導入すれば、Edit War の問題をほぼ解決できるのではないかと考えるのだ。 [...]