Dear All,
I have been following the various threads on tagged revisions.
As many of you know, we have been developing a trust coloring of the text of
Wikipedia articles. The trust value of a word depends on the computed
reputation of the author of the text, as well as on the reputations of all
visitors to the page; for more information, see
http://trust.cse.ucsc.edu/where a demo is also available.
In a short time, we will have new (we hope better) version of the demo out,
and we will ask for your feedback; we plan by the end of October to have a
demo with all the English Wikipedia, as of the Feb 6 2007 dump (the last
complete one), colored. We are still a few months away from doing the
coloring for an on-line, up-to-date, version of the Wikipedia, but we are
working towards that goal.
It may be fun to start thinking at how tagged revisions and trust coloring
may fit together. My impression is that one would be able to get something
superior to either of them separately. For instance:
- If an article lacks a manually tagged revision, one could select as
"stable" revision a recent revision where as little text as possible is
marked low trust (orange background).
- Currenly, text becomes more trusted due to edits: if one edits a
paragraph, one lends a bit of her/his own reputation to the paragraph (on
the assumption that one reads the paragraph she/he is editing). A mechanism
similar to trusted revisions would enable users to say "I agree with this
paragraph and I have checked it" without need for editing it.
- If a manually tagged revision becomes quite old with respect to the
most recent revision (we can measure age both in terms of edit distance and
in terms of n. of intervening revisions), we could detect it, and offer
instead of the automatically tagged revision, a revision that is more
recent, and with no (or as little as possible) low-trust text.
- We could monitor articles where the tagged revision becomes old (as
above), and good candidate revisions are available later, and alert people
in the "watch list" of the article, so that they might consider going to the
article and tagging a newer revision.
These are just ideas that came on top of my mind; I am curious to know which
other suggestions or thoughts you might have. As I said, we are still more
than a month away from a version of trust coloring that works for the
up-to-date wikipedia, but since we are thinking of how to architect the
system, it might be worth to think at how it fits with tagged revisions...
Another issue is this: might it be that, once the trust coloring is
available, the need for showing tagged revisions by default is lessened? If
a trust coloring becomes only one click away, perhaps it is the
trust-colored and tagged revisions that should be available on demand, and
the up-to-date revision should be shown as default, as it has been so far?
I am very interested in your comments...
Best regards,
Luca
--- "P. Birken" <pbirken(a)gmail.com> wrote:
>
> No, this is indeed a valid concern. A feature that allows to unflag an
> article is not included. Unflagging sort of happens by creating a new
> version and flagging that one instead. So, once an article has been
> flagged, it is "in the system". However, initially no article is
> flagged.
Leaving aside the sighted flag for a moment, what about the quality version
flag? Suppose it is given erroneously, because someone made a mistake in
checking the sources for the article - this can happen easily. In that case
there should be a way to unflag the article, no?
Ulrich
>No, this is indeed a valid concern. A feature that allows to unflag an
>article is not included. Unflagging sort of happens by creating a new
>version and flagging that one instead. So, once an article has been
>flagged, it is "in the system". However, initially no article is
>flagged.
On en.wikibooks, a major concern is the ability to "freeze" a book during a semester so that students and teachers have a consistent book version to work from. That said, we would like to have a "stable" version of the book that appears to student readers while a "development" version can continue to be worked on in the background. I guess what I'm most interested in is:
1) The ability to show a flagged version of some pages to all readers by default, but allow development to continue on the "current revision" of the page.
2) The ability to show the current development version of pages that dont need to be frozen, by default.
Now, there are ways to do this kind of thing using clever page protections now, but I think it would be generally preferrable to have the flaggedrevs extension streamline this process for us. Is this kind of thing going to be feasible?
--andrew Whitworth
_________________________________________________________________
Kick back and relax with hot games and cool activities at the Messenger Café.
http://www.cafemessenger.com?ocid=TXT_TAGLM_SeptWLtagline
>As it is planned, the feature is simply too intrusive. Once an
>article is flagged as "sighted", there is no way back.
I have to wonder whether this is a valid concern or not? I have not read all the documentation, so forgive this post if it's totally ignorant. It has been my assumption that FlaggedRevs would allow us to flag an article, unflag an article, or update a flag on an artical. Ie, an article that has been flagged previously should be able to have that flag removed and the most current revision of the page displayed by default. Is this the case?
--Andrew Whitworth
_________________________________________________________________
More photos; more messages; more whatever – Get MORE with Windows Live™ Hotmail®. NOW with 5GB storage.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migrati…
Quality means reliability.
Somebody earlier compared the WP quality with that of a commercial article, such as a motor car. Because WP supplies INFORMATION the two are quite different. Here, though interesting, spelling mistake free, grammatically correct writing is important, I believe that RELIABILITY is the most important aspect, which means: most up to date correct statements without bias, without advertising, without spam, and of course without vandalised parts
My only worry is, that not just checking, but patrolling sometimes inordinately long articles which, in number now exceed two millions in enwiki, and growing, and all this on a shoestring will be a daunting task.
Louis
Errare humanum, et in errore perseverare stultum est
_____________________________________________________________________________
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
--- John Erling Blad <john.erling.blad(a)jeb.no> wrote:
>
> The last edit is most likely an edit by a trusted user that will
> autoconfirm his own edit.
I am under the impression that auto-confirmation will only be in effect for
new articles, but not for edits to existing articles. Wrong?
Ulrich
> Not letting unregistered users edit controversial pages at all is
> surely less intrusive than holding their edits for review?
Yes, because I think 99.9% of all unregistered user actions are reading, not
editing. Therefore we are dabbling with the unregistered user's Wikipedia
experience in a much larger way - not by holding their edits, but by not
showing the most current version (which, by the way, will in most cases not
even be an anonymous edit).
Ulrich
--- "Gregory Maxwell" <gmaxwell(a)gmail.com> wrote:
> I think it
> is widely believed that mark as patrol failed for most projects
> because it was only a marker that didn't actually do anything
> important so nothing encourages people to keep up with it. The
> flagging system solves that issue by influencing the default page view
> for the public... something most Wikipedians will care a lot about.
Which is precisely why I think it is unwise to force this feature onto the
communities in this way. Flagging is a feature (although a superflous one, as
we already have enough ways to flag an article), but not showing the most
current version to anonymous readers is a policy change.
I guess there are some articles, where vandalism is a huge problem and it
might be alleviated with flagged revisions. But an easier and less intrusive
way would be to just disable anonymous editing on these pages. And for 99% of
all articles vandalism is occasional and easily dealt with.
Ulrich
Hi there,
I'm a writer from the German Wikipedia, but not usually concerned with
politics or administration, so forgive me if I understood something
incorrectly. But to me it seems that there is no way to not use this
feature - it seems more like a new policy.
There are communities in Wikipedia around articles that belong together
thematically. Those communities watch over them, but the articles are
fairly complete, at least as far as the current community is concerned.
Most edits, excepting vandalism, are miniscule. If such a community now
decides it does not want to flag "its" articles, because they'd rather
work under the current rules, then they should be allowed to do so.
As it is planned, the feature is simply too intrusive. Once an article
is flagged as "sighted", there is no way back. It effectively forces the
community to keep on flagging, because otherwise a years-old version,
that may even have been flagged erroneously, would be shown to anonymous
readers instead of the current one.
I know many authors in the German Wikipedia, who see this issue in a
similar light: the whole editing process is becoming more complex, but
we are not getting any new writers for our article-communities and the
existing writers aren't getting any smarter because of flagging. Most of
us are unpolitical and even agnostic of most software features and/or
administrative processes - we just want to write. So don't shove this
feature down our throats. I think it is an interesting idea and may well
work, but it should be in effect for article-communities that want it
and can handle it, but others should be allowed to take a more
conservative approach.
Therefore I think we need a way to unflag revisions or change the
"anonymous users don't see the current version if unflagged" rule for
certain pages.
Ulrich