Flagged Revisions too intrusive

[Ulrich Mayring]

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

[Kurt Jansson]

Hi Ulrich!

Post by Ulrich Mayring
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.

If it ever takes more then 10 minutes to flag an article as "sighted" we
have a problem. And that would not be a problem of the sighted version
feature, it would be a problem of us not having enough people patrolling
the recent changes. A lag of edits to be sighted would just be the symptom.

But I am very optimistic that there won't be any serious backlog. We
have several very dedicated vandal fighters, they are the backbone of
our quality control system. The sighted version feature enables them to
do their work much more efficiently (no patroller needs to check an edit
another person has already checked; no edits get overlooked). This might
even motivate more people to engage in RC patrol because it shows them
what still needs to be checked.

Kurt

[Erik Moeller]

Post by Kurt Jansson
If it ever takes more then 10 minutes to flag an article as "sighted" we
have a problem. And that would not be a problem of the sighted version
feature, it would be a problem of us not having enough people patrolling
the recent changes. A lag of edits to be sighted would just be the symptom.

Even though I agree with Ulrich that it is wiser to trial something
like this as an on/off switch on selected pages (yeah yeah, I don't
mind repeating myself), I am convinced that it will be possible to
improve the scalability of the feature quite massively. There are
quite a few things we aren't doing yet, including

- mass review (showing a slice of 20 suspicious diffs on a page and
asking a person to sight them for vandalism)
- applying a set of heuristics to rate the "supciousness" of an edit
in the same way spam filters do, including constant filter improvement
through Bayesian algorithms
- making it easier to authenticate from other sites (this is post
Single User Login!), and using that authentication information for the
"suspiciousness rating". For example, someone who can authenticate as
a University Professor is probably more trustworthy than a TOR user.

Post by Kurt Jansson
From an editor's point of view, it would even be possible to send an

instant notification once an edit has been approved. Which, in some
ways, is even cooler than making the edit yourself, especially if it
happens within seconds. If reviewers don't mind being identified, we
could even allow immediate real-time interaction via chat.

My vision is that eventually, editors will have access to a "master
control center" for reviewing changes they are interested in. This
would integrate some of the real-time tools dedicated vandal fighters
are already using and plenty of new mechanisms.

While all of this is _hard_, it's not inconceivable. A talented small
group of developers with enough funding for a year or two could pull
it off.

Kurt, now that things are moving forward on the initial
implementation, perhaps the German chapter could pursue some funding
for further development in this area, e.g. through the EU? It will
probably take at least until early 2008 for the Foundation to become
capable to execute such things in a timely fashion, esp. now that we
also have to relocate.

[Gregory Maxwell]

Post by Erik Moeller
Even though I agree with Ulrich that it is wiser to trial something
like this as an on/off switch on selected pages (yeah yeah, I don't
mind repeating myself), I am convinced that it will be possible to
improve the scalability of the feature quite massively. There are
quite a few things we aren't doing yet, including

[...]

You have some good suggestions there: some that have been around for a
while too and not implemented (mass review), some which are partially
implemented via external tools for some projects already (content
based reverting is done by some bots on enwp for example
http://en.wikipedia.org/wiki/User:ClueBot), and some ideas I hadn't
previously seen (third party credentials).

To add to this discussion I'd like to point out that the review
process for the flagging should be a lot like the review process
people are already doing with watchlists and recent changes.

If you accept the idea that they should be similar then I think there
are two possibilities:

(1) That the existing review processes are fairly effective at viewing
most revisions in a reasonable time. If this is true, then we already
have the resources and interest needed and flagging should not hurt.

(2) That the existing review process is not reaching most pages in a
reasonable amount of time. If this is true then we will have some
challenges getting enough effort behind flagging, but it is all the
more important that flagging be enabled since if this theory is true
then our sites are frequently distributing completely unchecked
content.

My expirence tells me that (1) is probably true and that the gaps we
currently have in our checking are due to the lack of ability to track
checked pages in a scalable way. Flagging solves that issue.

Mark as patrolled also solved that issue, but mark-as-patrolled was a
failure on most projects (although the Dutch still use it). 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.

[Kurt Jansson]

Post by Erik Moeller
Kurt, now that things are moving forward on the initial
implementation, perhaps the German chapter could pursue some funding
for further development in this area, e.g. through the EU?

I think it's worth trying if we can find a support programme where this
fits in. I'll ask Jakob Voß to look into this.

Kurt

[ulim]

Post by Ulrich Mayring
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

[Erik Moeller]

Post by ulim
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.

Not letting unregistered users edit controversial pages at all is
surely less intrusive than holding their edits for review?

[Tim 'avatar' Bartel]

Post by Erik Moeller

Post by ulim
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.

Not letting unregistered users edit controversial pages at all is
surely less intrusive than holding their edits for review?

Perhaps this is a misunderstanding by the OP.

There would be additional overhead, if the edits by the named
"article-communities" have to be flagged - but this wouldn't be the case
in 99,9% of the time, because it's highly likely that these persons
accomplish the requirements of flag articles as sighted by themselves.

But the edits by authors who are allowed to flag articles as sighted are
flagged as sighted automatically. So there would be no additional work
and no delay.

Bye, Tim.

[Platonides]

Post by Erik Moeller

Post by ulim
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.

Not letting unregistered users edit controversial pages at all is
surely less intrusive than holding their edits for review?

Add a protect-status where the page shows the stable version?
(add view to edit, and move which can be set to on, off, and default)
Then have a default action for pages with flagged revision and no
specific action, decided by the wiki policy.

[Erik Moeller]

Post by Platonides
Add a protect-status where the page shows the stable version?

That's the configuration Jimmy, Florence and I prefer. WMF will hire a
contractor to implement it if no volunteer does so in the next few
days.

[ulim]

Post by Erik Moeller
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

[John Erling Blad]

The last edit is most likely an edit by a trusted user that will
autoconfirm his own edit.

I think it is urgent to make a demosite to show people the system and
how it works.

John E

Post by ulim

Post by Erik Moeller
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
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

[P. Birken]

Post by ulim

Post by Erik Moeller
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).

This makes the assumption that Sighted versions won't scale. If they
do scale, readers will usually see the current revision. If they do
not scale, they won't and then the concept would have to be rethougt,
improved or scrapped. In the development of the feature, we have
discussed usability and scalability and lenght and put a lot of effort
into this. And we still want to improve this in the betatest! So all
in all, please wait for the betatest and have an actual look at the
software before making judgements.

Bye,

Philipp

[ulim]

Post by John Erling Blad
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

[P. Birken]

Post by ulim

Post by John Erling Blad
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?

Yes, that's wrong. If the current version is sighted and somebody with
the right to flag articles as sighted creates the next version, it
will also be automatically be sighted.

Bye,

Philipp

[Andrew Whitworth]

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

[P. Birken]

Post by Andrew Whitworth
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?

No, not at the moment, but it will be developed, except for one
problem: this is a question of global setting. So, if en.wikibooks
doesn't want this flexibility, but simply always to show a sighted
version, then a per-page-view is not possible.

I'm sure that soon, someone will provide tools to extract quality
versions from a wiki. Then you could put the frozen version on a
different website for example, which seems to me to be actually the
easiest solution to your problem anyhow (and those of many other
people).

Best wishes,

Philipp