Gesichtete Versionen
FlaggedRevs (Flagged Revisions) is an extension of MediaWiki that allows one to flag versions of articles and thus give additional information about quality. This comes with the possibility of changing what an Nicht registrierter Benutzer sees by default. The technical description can be found at mw:Extension:FlaggedRevs.
The actual usage and configuration of the extension varies a lot; usually, the feature enters into effect on a page only after it's "reviewed" (flagged) at least once, so it takes a committed community (in terms of active editors and guidelines) to actually enable it on a large wiki. For instance, the German Wikipedia uses the feature on 99.99 % articles considering it the default process; while the English Wikipedia uses it on less than 0.05 % articles with a non-standard configuration, for some special cases. More information on this spectrum follows.
Classic Flagged Revisions: German Wikipedia example
Here we will describe how the concept is used in the test on the German Wikipedia and what it is good for. First of all, there are two types of flags: Sighted and Quality. These come with two new user groups: An editor is able to flag versions as sighted, a reviewer is able to flag as quality.
Sighted means that an article has been looked at and does not contain vandalism. Quality means that a real content check has been done. Because the first check is not a big thing, any admin can give editor rights and there is an automatic process for giving this right. Currently, if you have edited for two months and did 200 edits in the main namespace, then you can get the editor right. The reviewer right for quality flag can be given only by bureaucrats and it is not in active use.
- What do flagged revisions accomplish?
- Flagged revisions give the reader an indication of the quality of the article.
- They assure a basic article quality (someone with basic trust has written this or checked it), if the last sighted version is shown to the reader.
- If only the last sighted revision is shown to the reader, they may make vandalism less attractive, although it is disputed whether vandalism decreased due to the adoption of flagged revisions.
- Generally, they provide a powerful tool for the control of new edits and patrolling the recent changes becomes more efficient:
- A new edit has to be checked for vandalism only once.
- Multiple edits in a row can be checked.
- If an article was vandalized and subsequently edited by a trusted user, vandalism was often hidden. This is no longer possible.
- No edit is forgotten.
- More people are able to find edits that were not sighted yet.
- Combined with categories, this becomes really powerful, since wikiprojects/portals have the possibility to oversee their whole area for new edits.
- They provide a useful system of revision labeling in general, increasing the information readers and contributors can derive from the history and about the article.
Edits can wait to be reviewed for a considerable amount of time, up to a month and a half as of 24 January 2016, and 15 days on average (see de:Special:ValidationStatistics). Edits awaiting review can be seen at de:Special:OldReviewedPages.
Pending Changes: English Wikipedia example
Classic Flagged Revisions were perennially rejected on the English Wikipedia. In 2009–2010, this new proposal emerged as an acceptable compromise for trial, which ended up being adopted on a permanent basis. The principle of pending changes (initially denominated flagged protection) is to allow administrators to enable flagged revisions on selected pages, when they meet criteria specified by the protection policy, typically an excess of vandalism or other policy-violating edits.
An important aspect of the feature is that edits by all autoconfirmed users (accounts older than four days and with at least ten edits), and not only reviewers, are automatically reviewed when the previous revision had already been accepted. Since edits by autoconfirmed users who are not reviewers to pages under pending changes with still unreviewed changes are rare, this means that almost always, autoconfirmed users can edit pages under pending changes without restriction. Thus, this is less restrictive than semi-protection. Additionally, there is an option to turn off this automatic reviewing of autoconfirmed non-reviewers, suggested for use on pages heavily targeted by sockpuppets which on occasion require full protection, however the use of this option has not gained consensus.
As of September 5, 2023, 3,880 of the 7,972,029 eligible pages (Article and Wikipedia namespaces) are using pending changes on enwiki (see en:Special:ValidationStatistics). Edits awaiting review are located at en:Special:PendingChanges, which has most of the time about half a dozen edits, none older than a few hours.
Other forms of Flagged Revisions
Other wikis may choose to use an amount of features somewhere between what the German Wikipedia and the English Wikipedia chose. For example, applying pending changes not by default on all articles, and not only on demonstrably problematic articles, but on a large subset of articles deemed particularly sensitive.
Flagged Revisions has also been suggested as a way to defer for review edits flagged as suspicious by the Abuse Filter, see w:Wikipedia:Deferred revisions.
Passive Flagged Revisions, working on the same principle but without affecting the version viewed by readers, has been suggested to improve patrolled edits, see w:en:Wikipedia:Patrolled revisions and w:en:Wikipedia:Deferred changes.
Setting $wgFlaggedRevsOverride = false; makes FlaggedRevs be just informative, doing "nothing" except adding review queues and banners/warnings: the latest version is always shown as on a "normal" wiki. Over 20 Wikimedia wikis use this configuration and many of them feel less urgency to go through the review backlog.
Flagged Revisions on Wikimedia projects
Flagged Revisions has been implemented on several wikis. The list below might not be up to date compared to the configuration file for all wikis.
- Wikipedia
- Albanian – enabled 7 November, 2010
- Arabic – enabled 6 August, 2009
- Alemannic – enabled 17 November, 2008
- Bosnian – enabled 8 April, 2010
- Belarusian – enabled 5 February, 2011
- Bengali – enabled 20 May 2011 (T30717)
- Chechen – enabled January 2014, (T58408)
- Classical Chinese – enabled 17 November, 2008
- English – enabled Pending Changes once again 1 December, 2012
- Esperanto – enabled 18 November, 2008
- Persian – enabled 22 May 2014 (T67452)
- Finnish – enabled 30 November, 2011
- Georgian – enabled 11 April 2011 (T26976)
- German – enabled 6 May, 2008
- Hindi – enabled 30 August 2010, reconfigured 8 August 2011 (T26622, T31911)
- Hungarian – enabled 17 November, 2008
- Indonesian – enabled 17 June 2010; reconfigured into Pending Changes on 15 July 2021 (T268317)
- Interlingua – enabled 19 March, 2009
- Central Kurdish – enabled 5 June 2014 (T67809)
- Macedonian – enabled 24 April, 2010
- Polish – enabled 17 November, 2008
- Russian – enabled 8 August, 2008
- Turkish – enabled 31 January, 2011
- Ukrainian – enabled 2011
- Venetian – enabled 29 November 2011 (T30837)
- Wiktionary
- German – enabled November 24, 2008
- Icelandic – enabled 19 March, 2009
- Polish – enabled 7 December, 2009
- Russian – enabled 17 April, 2011
- Ukrainian – enabled November 24, 2008
- Wikibooks
- English – enabled November 14, 2008
- Portuguese – enabled November 29, 2011
- Wikinews
- English – enabled August 5, 2008
- Persian – enabled October 25, 2010
- French
- Portuguese
- Russian
- Spanish – enabled 3 June, 2009
- Tamil – enabled 31 May, 2010
- Wikiquote
- Wikisource
For testing purposes, Flagged Revisions is also implemented on test2 wiki.
Undergoing trials
Rejected
- Wikipedia
- Persian – consequence didn't reach. closing at March 2011
- French – survey done October 2009.
- Other
- MediaWiki.org – enabled on 8 August 2009; disabled on 22 May 2014 with gerrit:134935 (announcement)
- Portuguese Wikisource – disabled on 20 March 2023
Wikis that want to request custom implementation of the feature can use these Bugzilla requests as models for their own requests.
Enabling
Notice of moratorium
As April 2017, there is a moratorium on the Flagged Revisions deployment to new wikis. (Dereckson @ T66726)
Flagged Revisions is extremely flexible; as such, it's complex to maintain (from a code point of view). The last new wikis added the extension in 2013 and 2014. In 2014 WMF tech first silently stopped enabling it without formal decision and then in 2017 by Dereckson's moratoira and RfC. Currently, WMF is trying to solve who should maintain it: Code stewardship review: FlaggedRevs – This extension has been deployed to prod around seven years ago and after a while, it became virtually without any maintainer, Technical debt in this code is unimaginable and in a matter of UX/UI it's non-standard and out-dated but any (of my) attempts to modernize it failed due to out-of-date and non-standard PHP code. (Ladsgroup, Jan 24 2018, phab:T185664) It is unlikely that new wikis will be enabled before this is solved OR the extension will be undeployed altogether.
Old process for enabling
The general process is the usual one for Beantragung der Änderung von Wiki-Konfigurationen, but proposers should also:
- fully translate the extension and the help page, get all translations reviewed at least once;
- send a patch for the shell request proposed configuration;
- get a test wiki for the language created on the beta cluster, test the translation and configuration there to ensure it's as intended;
- have someone monitor the effects and community response to the wider testing on the actual wiki after the enabling, and report it on Phabricator.
(This is the process followed by a recent adopter like the Finnish Wikipedia.)
Note: The section above was added in 2014.
The English Wikipedia trial
The English Wikipedia trial of a light weight form of flagged revisions known as pending changes, which eventually resulted in its permanent implementation, required at least one contractor hired to tweak and test the configuration, as well as development work involving no less than 8 Wikimedia Foundation persons in a period of 7 months from September 2010 to March 2011, according to reports.
Results
Lokal
There is no policy yet for disabling or denying the extension, but it's highly advisable that any wiki adopting it monitors results closely (at least on Wikistats and Special:ValidationStatistics), to ensure the feature is actually helping to reach the intended goals. As an example, a wiki could establish, as local community guideline/goal, documented in the local project page on the feature/process, a minimum "level of service" or "key performance indicators", like
- no more than X % total articles should be stale,
- (if applied to a subset of articles, e.g. previously protected) total edits and active editors on flagged articles should increase by Y %,
- average staleness of unreviewed edits shouldn't be above Z days and median time for review shouldn't be above W days.
Having such a shared understanding of the intended results will help a wiki reach a consensus on the opportunity to have/keep the feature enabled.
General
General results of Flagged Revisions on various projects are not known: there are few studies.
However, on several wikis, Special:ValidationStatistics shows a clear failure, in that there are peaks where
- the quota of total articles which have unreviewed edits is over 10 %, or sometimes even a majority of total articles,
- unreviewed changes are as old as 1000 days or more on average (this metric disregards how fast reviewed changes were reviewed),
- the time needed for unregistered users to have their edits approved is several days.
The more articles are using Flagged Revisions, the more severe the last two problems are; if only a handful pages are reviewed in the first place, average delays on those few pages are less significant for the wiki as a whole.
Where it's not actively used, the extension should probably be disabled. Regular cross-wiki reports on flagged revisions status have been proposed but not implemented yet. If you are or want to be a tool developer, this would be a nice thing to build and run on Tool Labs.
Interim reports
- FlaggedRevs Report December 2008 – report on FlaggedRevs usage across Wikimedia projects
- Hungarian Wikipedia FlaggedRevs test, october 2019 – shows that showing latest revision by default (setting
$wgFlaggedRevsOverride = false) increases the number IPs making edits by 100%, the number of edits made by IPs by 30%, and anonymous vandalism by 2-3 percentage points (which is a 10-30% relative increase, depending on how narrowly vandalism is defined) compared to showing approved revisions by default. No visible effect on registered users.