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
Hi Ulrich!
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
On 9/24/07, Kurt Jansson kurt.jansson@wikimedia.de wrote:
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.
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.
On 9/23/07, Erik Moeller erik@wikimedia.org wrote:
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.
Erik Moeller schrieb:
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
wikiquality-l@lists.wikimedia.org