On Sun, Nov 23, 2008 at 9:03 AM, Maury Markowitz <maury.markowitz(a)gmail.com> wrote: The UMN system intentionally included only a small number (70?) articles. This is why you needed to use the random page function to browse among them. This doesn't reflect any short coming of the system, but it most likely just reflects the limits of computational resources they were working under. [snip] Yes, I had exactly the same experience with the USCS system: Different coloring for text I'd added in same edit which created the article. Quite inscrutable. [snip] For the articles it covered I found the UMN system to be more usable: It's output was more explicable, and the signal to noise ratio was just better. This may be partially due to bugs in the USCS history analysis, and different a different choice in coloring thresholds (USCS seemed to color almost everything, removing the usefulness of color as something to draw my attention). Even so, I'm distrustful of "reputation" as an automated metric. Reputation is a fuzzy thing (consider your comma example), but time is just a straight forward metric which is much easier to get right. Your tireless and unreverted editing of external links tells me very little about your ability to make a reliable edit to the intro of an article, ... or at least very little that I didn't already know by merely knowing if your account was brand new or not. (New accounts are more likely to be used by inexperienced and ill-motivated persons) I believe a metric applied correctly, consistently, and understandably is just going to be more useful than a metric which considers more data but is also subject to more noise. The differential performance between these two systems has done nothing but confirm my suspicions in this regard. A simply objective challenge for any predictive coloring system would be to use them in the following experimental procedure: * Take a dump of Wikipedia up a year old, use this as the underlying knowledge for the systems. * Make several random selections of articles and include the newer revisions not included in the initial set up to 6 months old. Call these the test sets. * The predictive coloring system should then take each revision in a test set in time order and predict if it will be reverted (Within X time?). * The actual edits up to now should be analyzed to determined which changes actually were reverted and when. The final score will be the false positive and false negative rates. So long as e assume that the existing editing practices are not too bad we should find that the best predictive coloring system would generally tend to minimize these rates.

Maury, perhaps I can help explain the behavior you saw in the UCSC system (I am one of the developers). New text is always somewhat orange, to signal to visitors that it has not yet been fully reviewed. The higher the reputation, the lighter the shade of orange, but orange it still is (I have no idea of how high was your computed reputation when you started writing that article). Text background becomes white when other people revise it without drastically changing it: this indicates consensus. In our more recent code version, we also have a "vote" button; using this, text can more speedily gain trust without need for many revisions to occur. In a live experiment, where people can click on the vote button, I presume the trust of the text would raise more rapidly. Note that the code prevents double voting, or creating sock-puppet accounts to vote, etc etc. So I don't think based on what you say that the system is tripping over diffs. It is simply considering new text less trusted, and more revised text more trusted, which is what we wanted. It appears however we don't do a very good job on the web site describing the algorithm (I guess we put most of the description work in writing the papers... we will try to improve the web site). We don't measure "edit work" in number of edits, but in number of words changed. As you say, for our system, changing 1000 words in separate edits is the same (provided the edits are all kept, i.e., not reverted) as providing a single 1000-word contribution. We thought of giving a larger prize to larger contributions: precisely, of making the reputation increment proportional to n^a, where n is the number of words, and a > 1. This did not work well for the Wikipedia, because it ended up not rewarding enough the work of the many editors, who clean and polish the articles, thus making many small edits. Technically it would be trivial to change the code to include such a non-linear reward scheme (to adopt rewards proportional to n^a rather than n); whether it is desirable, I have no idea. It does not lead to better quantitative performance of the system, i.e., the resulting trust is not better at predicting future text deletions. Luca

Very good question. Author A would still get some reputation gain, due to the way we compute the edit distance. A would gain less reputation than if his contribution survived intact. Specifically, assume that there is a revision r0, A adds an n-words piece of text making it become r1, and B then rewrites A's contribution, obtaining r2. Due to the way we compute edit distances, we have: d(r0, r1) = n d(r1, r2) = n/2 d(r0,r2) = n So the quality of A's contribution is q = (d(r0,r2) - d(r1,r2)) / d(r0,r1) = (n - n/2) / n = 1/2 > 0 and A gets half of the reputation gain it would have gotten, had hes text not been rewritten. The reason d(r1, r2) = n/2 is that our algorithm distinguishes, when giving credit, replacements from insertions / removals. Note that people who insert pure spam have their contribution removed, not rewritten, so even with the above lenient treatment of replacements, spammers do not end up gaining reputation. When developing the reputation algorithms, we (Bo and I) went over hundreds of revisions which were marked with negative quality, checking that the author really deserved the reputation loss they got by authoring that revision. We tweaked the algorithms as a consequence; the treatment of replacements described above was introduced precisely to give reputation to authors, even in the face of wordsmithing or copy-editing. Luca On Mon, Nov 24, 2008 at 7:59 PM, J.L.W.S. The Special One < hildanknight(a)gmail.com&gt; wrote:

This comment is very interesting, and it points out that we most likely are using too dark shades of orange (this is customizable in php btw). We have 10 equally-spaced shades of orange, from the darkest (trust 0) to pure white (trust 9). According to the current coloring scheme, even text with trust 7, which has been revised etc, gets some visible (two steps down from pure white) shade of orange. It might be visually better to have 8,9 both as pure white, and lighten the shade of levels 6,7. In the new codebase, we have increased the speed at which text gains trust (we noticed also it was a bit too orange in that old demo). The vote button also helps text gain trust much more quickly, as people can just click there to validate the text, rather than having to do an edit. People can only raise the trust of text up to their own reputation level (which also goes from 0 to 9), so that spammers cannot enter an edit, then use sock-puppets to make the orange coloring disappear. Yes, we did compare the results with a trust system based purely on text age; see Figure 7 of http://www.soe.ucsc.edu/~luca/papers/08/wikisym08-trust.html On the Wikipedia, people are so dedicated that most pages are visited regularly, so age of text is a good indicator of text quality. Using a reputation system as we do enables us to assign medium trust (trust level 5) to the brand-new contributions by high-reputation authors (which means, in practice, anyone with a moderate history of good edits). If you go simply by text age, then you would end up assigning low trust to these contributions when they are brand new. Thus, the use of a reputation system enables us to assign _more_ trust to text. This is is why Figure 7 shows that the trust based on a reputation system is more precise: low trust is assigned more sparingly, and it is a more precise predictor of future deletions. In summary, on the Wikipedia the use of a reputation system enables us to: - Assign more trust to new text by good reputation authors - Make it hard for spammers to cause their contributions to become fully trusted. As Gregory points out, though, at least before the introduction of the vote button, our coloring had too much text in the lighter shades of orange. Whether this would remain a problem even after people can vote for the correctness of text, I don't know. We believe the vote button is very useful in enabling good text gain trust quickly. Also note that in many less-followed wikis than the Wikipedia, many pages remain unchecked for relatively long periods, so using text age there would not necessarily work well -- but I don't have data on hand to back this claim. Luca