[Wikiquality-l] Wikipedia colored according to trust

[Luca de Alfaro]

Dear Daniel,

I believe you are saying that:

   1. The trust coloring rightly colored orange (low-trust) some
   unreliable content,
   2. and the Wikipedia people were quick in reverting it.

Right?

About 1, I am delighted our methods worked in this case.  Note that we also
highlight as low trust text that is by anonymous contributors.  The text
will then gain trust as it is revised.  Also, we color the whole article
history, so if you want to see how things evolve, you can look at that.

About 2, I am very glad that bad edits are quickly reverted; this is the
whole reason Wikipedia has worked up to now.
Still, it might be easier for editors to find content to check via the
coloring, rather than by staring at diffs.
Other uses, as you point out, are:

   - Burning the content on DVDs / Flash memory (wikisticks?)
   - Making feeds of high-quality revisions for elementary schools, etc
   - Generally giving readers (who unlike editors do not do diffs) that
   warm fuzzy feeling that "the text has been around awhile" (can this help
   answer those critics who mumble that the wikipedia is "unreliable"?)
   - Finding when flagged revisions are out of date (there may be a new
   high-trust version later)

BTW, as the method is language-independent, we look forward to doing the
same for wikipedias in other languages.

Luca


On Dec 19, 2007 3:32 PM, Daniel Arnold <arnomane at gmx.de> wrote:

> Am Mittwoch, 19. Dezember 2007 22:36:37 schrieb Luca de Alfaro:
> > we have a demo at http://wiki-trust.cse.ucsc.edu/ that features the
> whole
> > English Wikipedia, as of its February 6, 2007 snapshot, colored
> according
> > to text trust.
>
> I looked at the demo at http://wiki-trust.cse.ucsc.edu:80/index.php/Moon.
> Most
> remarkably in this example is a whole section with a private original
> research theory on "Binary planet systems". So sadly (or luckily? ;-) the
> latest version in your snapshot contains a bad edit; compare it also to
> the
> relevant edit in Wikipedia:
> http://en.wikipedia.org/w/index.php?title=Moon&diff=prev&oldid=107099473
>
> So your algorithm highlighted the wrong content. The problematic part is a
> bad
> summary of an older origin of moon theory which is beeing described here
> overly simplified with some ad-hoc-erisms and thus is made even more wrong
> by
> the author of these lines (OT: I probably know the author of these lines
> from
> de.wikipedia: he tried to post this and other private theories in several
> astronomy articles).
>
> Ok. How did Wikipedia work out in that case? It took a little more than an
> hour to revert this. So Wikipedia was able to resolve this problem with
> the
> current tools rather quickly. :-)
>
> This doesn't mean we don't need your stuff. Quite the contrary. I come to
> some
> very promising and interesting (and maybe non-obvious) use cases:
>
> 1) The (German) Wikipedia DVD.
> The basis of the Wikipedia DVD is a database dump. The first Wikipedia CD
> and
> DVD contained an "as is" snapshot transformed to the Digibib reader format
> of
> Directmedia Publishing GmbH
> (http://en.wikipedia.org/wiki/Directmedia_Publishing). However these
> snapshots had the above problem with short lived nonsense content that
> happened to be in the snapshot. For the DVD's up to now different trust
> metrices were used in order to find the "latest acceptable article
> version"
> out of a given snapshot. One metric was the "latest version of a trusted
> user". The current DVD from November 2007 uses a "user karma system" in
> order
> to find the latest acceptable version (see
> http://en.wikipedia.org/wiki/Directmedia_Publishing if you can read
> German,
> however the karma system doesn't get described there). So I think
> that "offline Wikipedias" such as the Wikipedia DVD and Wikipedia read
> only
> mirrors would benefit a lot from your effort in order to know which most
> recent version of a given article is the one they should provide to their
> readers.
>
> 2) A combination with the reviewed article version.
> Several people pointed out that they fear the reviewed article version
> need a
> lot of checks depending on configuration mode if latest flagged or current
> version is shown by default. Furthermore there are different opinions
> which
> one of both modes is the best.
> How about this third "middle ground" mode: If the karma of a given article
> (according to your algorithm) version falls below a certain karma
> threshold,
> the latest version above this theshold is shown by default to anon readers
> if
> there is no newer version flagged as reviewed.
> That way anon people usually see the most recent article version and we
> always
> can overrule the alorithm which is a good thing (TM) as you never should
> blindly trust algorithms (you know otherwise people will try to trick the
> algorithm, see Google PageRank).
>
> The drop below a certain karma threshold could be highlighted via a simple
> automatically added "veto" flag, which can be undone by people that can
> set
> quality flags.
>
> That way we would have three flags (in my favourite system): "veto",
> "sighted"
> and "reviewed". The veto flags makes only little sense for manual
> application
> cause a human can and should (!) do a revert but it would be very useful
> for
> automatic things (automatic reverts are evil).
>
> Cheers,
> Arnomane
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikiquality-l/attachments/20071219/526cd03d/attachment-0001.htm