Requests for comment/Flagged revisions deployment

The following request for comments is closed. As this RfC has been lingering for several years, and new contributions are mostly additional wiki's showing an interest, I'm moving on and closing this as inactive. I don't think this will lead to consensus without rigorous reframing of the question and background information. Effeietsanders (talk) 06:30, 2 September 2018 (UTC)[reply]

Flagged Revisions is one of the first anti-spam solution designed to stop spam and offer to readers a stable, validated, official revision on Wikimedia wikis. It's currently implemented under various forms (full, limited to a specific articles, etc) on a few Wikimedia wikis, most known example is the German Wikipedia.

It allows hundreds of different configurations, but the main set-up which is used in German Wikipedia is to show readers only a 'validated' version of a page, and hide any new change pending this validation. Other common configurations are to show latest version as default and use Flagged Revisions as workflow for checking the all changes which are made by new or unregistered users. This is used in Finnish Wikipedia.

Problem

Over the last few years, requests to deploy Flagged Revisions on new wikis have stalled for several reasons:

new tools and ways to fight vandalism exist, for example global Abuse Filter rules, though nothing which could replace the FlaggedRevs in context of workflow
even on the largest wikis, getting enough people to review unflagged revisions often enough to make the wiki work is very hard;
the system has led to some very major adverse changes in the communities of some of wikis on which it has been deployed;in which communities and how?^[unclear]
we dont really know how different communities are using Flagged Revisions
configuration isn't trivial and there is no good default settings examples for communities so it is made by trial and error
no-one in the developer community is really willing to handle these requests, given the very large amount of work involved.
Lack of development, one source of the "getting enough people to review unflagged revisions often enough to make the wiki work is very hard" is because UI.

Yet, new requests still come in from time to time.

The requesting users are normally asked for which root problem they are trying to solve, and offered alternative solutions, but sometimes no real and attractive root reasons are ever given. So, mainly, communities require the extension because they think that could be useful, but we don't know what they expect to achieve. The current standard practice is to requires that any new deployment is for a temporary period, with defined 'success' criteria set before starting, and that the tool is removed if the criteria are not met.

To complicate the matter, new small communities like to do extension and config shopping, to have all their wikis configured like some of the bigger wikis. In their process, they can request Flagged Revisions in their configuration without significant planning about the huge impact this request can have on their community.

This situation, in which we "soft" deny these requests, is uncomfortable. Requests are rarely formally refused, and even when they are, someone will often re-open it with hope that one day the situation will change – perhaps, that someone will accept the work of creating the config change and that someone will deploy it anyway. Some wikis believe that their community consensus should be the law and so enforced regardless of what other people say, and that once they've established consensus, it's too late to point out any problems.

Suggestion

We should adopt an official deployment policy related to FlaggedRevisions, both for new deployments and possibly for changes to existing ones.

I (User:Dereckson) offer to discuss two strategies to handle flagged revisions deployments requests:

Decide boldly we don't want any new Flagged Revisions deployment on the Wikimedia cluster: we keep it for current wikis, but any new requests will be denied and current pending requests will be denied too; or
If we want to continue to use this extension, we can devise together a workflow and conditions to deploy it, at least ask them systematically a compelling use case, something a combination of revision scoring vandalism fighting bots, AbuseFilter, human RC patrolling can't handle. Code is more or less abandoned so there should be vision how to develop it further.

I, User:Wikisaurus, suppose that one should not try to intervene with the solution of other Wikiprojects unless there is some fundamental problem. I also remind you that one should not write RfC's without analysis of both sides: not only contra's, but pro's.

Current status (april 2017)

We aren't deploying Flagged Revisions on new wikis as long as the global community (for example though the meta RFC) don't send a strong signal they still want we deploy this extension., Derekson @ T66726

Propaganda quotes

FlaggedRevs is bad and you should feel bad.
In FlaggedRevs we trust.

Relevant links

Statistics from Wikipedias with different configurations

Zache compiled and prepare these statistics from some Wikipedias where Flagged Revisions is in active use.

German Wikipedia: Stable version is shown to readers, most editors will be autopromoted to reviewers and reviewlag is pretty stable
Finnish Wikipeda: Latest version is shown to readers and FR is used to be sure that all edits by unregistered users or new users are checked against clear vandalism. Editors are promoted by hand and basically all regular users can be editors if they want. Currently in Finnish Wikipedia is also asking before they promote anybody if user actually want to check any changes. Right can be toggle on/off by users own reguest. Reviewlag is low mostly because there is review notification link in left toolbar for easy access to pending changes.
Hungarian Wikipedia: Stable version is whown to readers, small number of users with editor right (there is dedicated user group like admins which are checking the edits?). Reviewlag is increasing until there is ~4000 articles in pending changes queue and then queue is emptied.


Project	German Wikipedia	Finnish Wikipedia	Hungarian Wikipedia
Active users	19,280	1,670	1,729
Users with Editor rights (who review edits)	16,501	830	153
Autopromote in use	yes	no	no
Which version is shown to readers?	stable	latest	stable
Reviewed pages NS0 (number of pages which are tracked via FR)	1,938,751	329,444	386,925
Outdated / Pending	12,887	114	2,845
Average review delay for pages with edits currently pending review	17 d 17 h	10 h 54 min	28 d 10 h
Average wait for edits by users that have not logged in to be reviewed	14 h 51 min	1 h 43 min	25 h 59 min
Median wait for edits by users that have not logged in to be reviewed	1 h 30 min	18 min 35 s	3 h 38 min
Date of the stats	13.5.2016	13.5.2016	13.5.2016
Tools
Validation statistics	de	fi	hu
Special:Statistics	de	fi	hu
Wikimedia statistics	de	fi	hu
Wikimedia summary	de	fi	hu
Edit and revert trends	de	fi	hu


Project	FR installation year	Which article version is shown	Target articles	Autopromote	Pending queue length	The average wait for edits by users that have not logged in	The median wait for edits by users that have not logged in	Active editors (yearly change)	New editors (yearly change)	Wikipedia Statistics	Wikimedia statistics	Edit and revert trends
Alemannic	2008	latest	all	no	short	32 h 57 min	21 min 14 s	declining	rising	als	als	als
Russian	2008	latest	all	no	infinite	12 d 15 h	13 d 4 h	stable	declining	ru	ru	ru
German	2008	stable	all	yes	< 1 month	14 h 51 min	1 h 30 min	stable	declining	de	de	de
Polish	2008	stable	all	yes	< 1 month	9 h 36 min	1 h 35 min	stable	declining	pl	pl	pl
Esperanto	2008	latest	all	yes	infinite	4 d 20 h	3 h 46 min	rising	declining	eo	eo	eo
Hungarian	2008	stable	all	no	< 1 month	25 h 59 min	3 h 38 min	stable	rising	hu	hu	hu
Arabic	2009	stable	all	no	infinite	41 h 29 min	26 h 42 min	declining	declining	ar	ar	ar
Interlingua	2009	latest	all	no	infinite	10 d 8 h	13 d 23 h	declining	declining	ia	ia	ia
Hindi	2010	latest	protected	no	short			stable	stable	hi	hi	hi
Albanian	2010	stable	all	yes	infinite	4 h 50 min	7 h 15 min.	rising	rising	sq	sq	sq
Indonesian	2010	stable	all	no	infinite	40 d 4 h	8 d 10 h	declining	declining	id	id	id
Georgian	2011	stable	all	no	short, infinite	46 h 9 min	1 h 11 min.	stable	declining	ka	ka	ka
Finnish	2011	latest	all	no	short	1 h 43 min	18 min 35 s	stable	declining	fi	fi	fi
Bengali	2011	latest	protected	no	short			declining	declining	bn	bn	bn
Turkish	2011	stable	all	yes?	infinite	10 d 9 h	2 d 2 h	declining	declining	tr	tr	tr
Ukrainian	2011	latest	all	no	infinite	49 d 20 h	13 d 19 h	rising	stable	uk	uk	uk
Venetian	2011	latest	all	no	short,infinite	9 d 12 h	4 h 25 min	stable (small)	declining (small)	vec	vec	vec
Belarusian	2011	latest	all	no	short	9 h 55 min	3 h 24 min	declining	declining	be	be	be
English	2012	latest	protected	no	short	39 min 7 s		stable	declining	en	en	en
Portuguese	2013	latest	protected	no	short	very small		declining	declining	pt	pt	pt
Persian	2013	latest	protected	no	short	2 d 21 h		rising	stable	fa	fa	fa
Chechen	2013	latest	all	no	infinite	66 d 14 h	8 h 58 min	declining (small)	declining (small)	ce	ce	ce

Legend

For the purpose of this table, a change of not more than +5% or -5% is interpreted as "stable" in the columns Active editors (yearly change) and New editors (yearly change). More than +5% or -5% are interpreted as "rising" or "declining", respectively.

Which article version is shown – Is table or latest version shown by defalut. (wgFlaggedRevsOverride setting)
Target articles – Is FR used to track whole NS0 or just protected pages (wgFlaggedRevsProtection setting)
Autopromote – Is autopromote in use or is user rights managed by hand
Pending queue length – The average review delay for pages with edits currently pending. Infinite means that Wiki doesn't try to solve backlog. Short means that single person can check it through in one day.
Editor count trend – are number of editors declining or rising.

Russian Wikipedia style configs: Green rows are Russian Wikipedia style configurations where changes to all articles are tracked and backlog is allowed to grow. Most of the installations are configured so that latest version of the article is visible by default.

German Wikipedia style configs: Blue rows are German Wikipedia style configurations where changes to all articles are tracked and changes are checked in orderly manner so that backlog doesn't grow. Most of installations are configure so that the stable version of the article is displayed by default.

English Wikipedia style configs: Yellow rows are English Wikipedia style configurations where only changes to selected articles are tracked and changes are checked in orderly manner so that backlog doesn't grow.

Discussion

Case Finnish Wikipedia

This is how Finnish Wikipedia installed the Flagged Revisions in 2011. Not really example of problems but an example how it was done

In Finnish Wikipedia we had two or three different larger discussions in 2009 - 2011 before we decided to ask Flagged Revisions to be enabled. Most largest topic was about do we want German Wikipedia style configuration where stable version is shown to readers or do we want to show latest one. Another point was about if we have the workforce to check all the edits. We also translated the FR to Finnish when enabling was discussed.

Eventually fiwiki decided to go with lightest possible configuration which was only living persons and quality articles and the latest version of the article should be shown to user by default. In decision there was also that after 6 month testing period there should be second vote where fiwiki if the use of Flagged revisions is continued

However there was couple of things which we didn't see before hand. One was that there was no practical way to limit FR to certain articles with our configuration. So when FR was enabled it was visible in all articles AND users initially reviewed pretty much anything without limiting FR to quality articles or living persons. Also how to use different review levels was total mystery to us and it still is. With current configuration with three levels are nice gimmick but unusable. Also we decided that there should be report and second voting of using FR when we have some experience about it, but eventually we didn't done any second voting and everybody seem to be happy with it.

Bugzilla timeline

4. April 2011: Fiwiki decided to test Flagged revisons.

6. July 2011: Request to bugzilla (phab:T31742). Answer was that installation was blocked by phab:T31744 where was no reason given at the time and some months later FR was installed anyway.

However some years later Jdforrester-WMF answered in phab:T31744 to my question: After talking this through with colleagues, our answer is that we are not accepting new wikis to enable Flagged Revisions, given the very significant problems that Flagged Revisions poses in terms of engaging new users, adding complexity and confusion to the existing too-hard-to-understand interface, and badly impacting the quantity, quality and depth of the wikis on which it has been used. Sorry for the slowness of the response.

29. November 2011: Reedy did the changes. There was no prior notice for enabling after months silence so this caught us by suprice. There was translation changes so there was untranslated texts in UI and there was also some real UI bugs too so we did a quick and dirty fix and hid whole thing via css. Those people who wanted to see it could enable it with gadget.

Translatewiki -> fi.wikipedia.org translation transfer was also down at the time so we fixed translations locally and switched to translatewiki translation when it started to working again. (phab:T34767 etc)
5. December 2011 - 8. December 2011: Asked for some group changes based on weeks use and also asked to change Flagged revisions default UI to full UI because small UI was broken in fiwiki. (done 8. December 2011)
10, 15, 16. December 2011 - 26. December 2011: Asked to change reviewer right to defaults because reviewer setup didn't seem to do anything. Asked to reverted rollback change because it caused human errors (too many misclicks with touchescreens etc) (done 26. December 2011)
27. December 2011 - 21. January 2012,: Second try with reviewer. Problem with new reviewer setup was that if article was reviewed to level 2 then it blocked the editor user group from doing any reviews to that article. (done 21. January 2012)
23. January 2012 - 22. February 2012: still some autoreview problems to fix. We eventually solved them locally and dropped the issue. (22. February 2012)
3. September 2012 - 18. September 2012: Asked to disable Recent changes patrolling because it was redundant because it was replaced by Flagged revs (phab:T41942) (done 18. September 2012)
14. October 2012 - 22. October 2012: Asked to re-enable recent changes patrolling because when it was disabled the special:NewPages lost visual indicators for already checked pages. Also special:log was flooded by patrolling events which are hidden by default when rc patrolling is enabled and re-enabling fixed that too. done 15. October 2012)

There was also UI-tweaking locally in fiwiki to streamline the reviews process with gadgets, discussions how FR should be used and discussions like should we make initial reviews to all ns0 articles with both or review everything by hand. Community view was lets do initial reviews by hand and it is fine if it take years. --Zache (talk) 08:47, 13 May 2016 (UTC)[reply]

Fiwiki experiences

Good

FR is very effective against vandalism and for finding broken edits. More generally it is very effective with all edit problems which are straightforward to fix
Reversed order (oldest first) of checking changes reduces edit collisions
There is no need for watching continuously the RC feed because unchecked edits are in pending changes list.
Only deltas are checked which reduces needed approve counts
reviewer right / autoreview right works socially like trust and it reduces fights between editors.
attitude towards ip-editors is more realistics. Because we are checking now all the ip and new user edits nobody is saying any more that all IP editors are enemy number one and they should be blocked OR all IP edits should be sourced etc... Also from IP:s there is incoming lot of our edits which are related to updating and finding the errors. However it is also clear that there is lot of stuff that which needs copy editing (fixing errors, wikifying, reffing etc) before incoming edits are usable and it is regular editors work.
Concept is intuitive and easy to understand. You can explain it some on who isn't familiar to wikipedia and s/he understand it.

Bad

User interface is not made for checking all the edits in realtime. In fiwiki we are solved problems with gadgets.
Edits which have big problems and you have to use lot of time to fix it (but you cannot just revert it) are problematic, because they are staying in the queue.
Demands for reviewer and writers tend to be too high. Currently in fiwiki about 40-35% of the edits are checked. If same amount of time would be used it would be better if 20% of the edits would be checked and more time would be used for curating. (eg reviewers or editors dont need to be perfect, it is enough for wikipedia that their changes are making it better)
Integration between FR and the Wikipedia tools should be better. (Abusefilter and FlaggedRevs, Wikipedias special pages...)

--Zache (talk) 13:20, 17 May 2016 (UTC)[reply]

Case Norwegian Wikipedia

Norwegian Wikipedia is pretty much same size than Finnish Wikipiedia and it requested the enabling of Flagged revision at 2014 (phab:T66726) with same style settings than fiwiki. (Discusions: first, second) [[Eg. changes would be visible to all by default and large reviewer base. Main difference to fiwiki is that there is autopromote in use and in fiwiki users are promoted manually. Nowiki also used Pending changes for recent changes tracking so they should have been able to handle also the FR queue least as well than fiwiki.

About the bugzilla ticket process itself Mjbmr:s suggestion in the last comments was good intented. eg: remove 'reviewer' user group and add rights directly to editor, but Mjbmr didn't say why it should be done so and somehow i think that Jeblad missed the point. It was good idea because it would have simplified the config and result would have been same. (It would have been like in fiwiki where there is autoreviewed users and reviewers, which i think that they tried to do with their config). However this was first comment about how the configuration should be done in whole ticket.

Also nowiki was soft denied by inaction even though Eloquence green lighted it at the ticket comments. --Zache (talk) 11:42, 13 May 2016 (UTC)[reply]

A proposed configuration was always in place, even from the opening comment May 1 2014. We had a lengthy discussion on-wiki about how the configuration should be, including how present roles in our patrolling setup should be mapped to the new roles. It took a month before Aklapper asked for progress, and yet another month before Jforrester started discussing policy and even stating something that was some kind of official statement. In the end of July the process for setting up FR was changed, and we did (I did) the necessary followups. Several pointed out that this had been discussed at length at WP:Tinget. Then Eloquence asked for more time, I guess it was because there was no official policy, and then he came back with additional questions in the end of August. He got a prompt reply Sept 1, with further discussions in September. We even voted in September to clarify our standing. In mid October I notified the involved people that the thread was archived at nowiki, and posted the links. In March 2015 there was another complaint about missing progress, but that was a void claim due to new source strings being added. Then there is a proposal in April that would go against the present community consensus. Note that the proposal ends with an question about what is our (my) proposal, but that is posted one year earlier and is formulated from the discussions in the community.

I have no real clue why this request is stalled, except that someone at WMF obviously don't like the extension. What really bothers me is that WMF by this goes against the community at nowiki with no real explanation why. — Jeblad 13:52, 13 May 2016 (UTC)[reply]

@Jeblad:, is nowiki still interested for installing the Flagged rews? If so then it could be case example what Dereckson asked and even if WMF will deny the installation it would be nice to have some answer for what they are planning with the extension. --Zache (talk) 08:07, 16 May 2016 (UTC)[reply]

A decision on this would not be up to me, but up to the community. — Jeblad 10:58, 16 May 2016 (UTC)[reply]

About Mjbmr:s comment in the ticket. If i correctly understand your Nowikis config, then with those config there would be following user rights:

autoreview which comes from Flagged Revision default config which can be given manually.
editor with autopromotion and following rights: "review", "unreviewedpages", "unreviewedpages", "movestable" which all come from default config. Editor also have "autoreview" right which come from both default config and your config.
reviewer following with rights: "autoreview", "review", "stablesettings" from both your config and default. Reviewer also have rights "validate", "unreviewedpages", "movestable" from flagged revs defaults.

If i guess right then you tried to create editor which would be identical with autoreview? (eg user which edits are automatically reviewed, but it cannot review). And the reviewer user would be the user which would be doing actual reviews? If so then you would have to remove default rights in your config. Even better solution would be that what Mjmbr suggested that you would use autoreview and editor users because you dont need change the default settings and it would be also in line with other Wikipedias FR settings. Visible names of the user rights can be tuned with translations so it doesn't really matter what is the internal name in the configs. In dewiki's config there is also example how autoreview right can be autopromoted. --Zache (talk) 08:40, 16 May 2016 (UTC)[reply]

Flagged revisions damages the community?

Jdforrester_ editet to this RfC that the system has led to some very major adverse changes in the communities of some of wikis on which it has been deployed and couple years before After talking this through with colleagues, our answer is that we are not accepting new wikis to enable Flagged Revisions, given the very significant problems that Flagged Revisions poses in terms of engaging new users, adding complexity and confusion to the existing too-hard-to-understand interface, and badly impacting the quantity, quality and depth of the wikis on which it has been used. Sorry for the slowness of the response..

This is WMF:s opinnion i guess and reason why they don't like to enable Flagged revs to new Wikipedias, but is there any actual data or examples for backing this up?

In example FR didn't made any clear difference in fiwikis trends, which are bad but they were bad long time before Flagged revisions installation. Norwegian, Swedish and Danish Wikipedia's trends are declaining without any help of FR.

Also FR most likely may impact to the quantity and depth of the wikis by limiting incoming content, but most likely it also increases quality. However i don't know if anybody is tried properly measure the impact of FR to quality, but least in fiwiki number of articles without any sources was stalled to 120000 articles and after FR it started to decline and now number is something like 100000 [ 1 ]. --Zache (talk) 12:24, 13 May 2016 (UTC)[reply]

I see a lot of statements that FR may impact to the quantity and depth, but no documentation that so actually happen. Note that the pending changes setup where all changes are shown immediately will not (and can not) have any impact on edits done by neither new editors or old editors, except for a small loss in available time to write new contributions for old editors (aka patrollers, which on nowiki will be lost anyhow as we do extensive patrolling). Also, it is true that some of the stats for nowiki has declined over several years, but during the last year the trend seems to be changing. See for example Users with more than 100 edits and New articles. — Jeblad 14:02, 13 May 2016 (UTC)[reply]

I think that one reason how it would impact to quantity and depth is that (least in fiwiki) Flagged revisions allows to enforce policies like no original research and verifiability. Before FR it didn't matter because without effective way to track changes people would anyway write what they wanted and additions were passing most of the time without reverting unless the change was clear vandalism. With FR there was effective way to track changes so policies were enforced too. This is true least with fiwiki, but most likely it is true also with de/hu/pl wikis too which are checking all ip/new user changes in organized manner.

Another obvious reason could be that workload for checking changes in the way what fi/de/hu/pl does is pretty hard. Basically thing is that revision checking is working fine as long amount of edits to check is so low that it can be handled easily. If it goes over that then it will stress people out and eventually wiki needs to change how it is using the FR. I would guess that ignoring the backlog is one of the such changes. However if it is well planned and done then infinite backlog would be perfectly valid way to use FR too and for some wikis it seems to be working in terms of community growth. Another way to handle scaling problems is enwiki's protection setup, which focuses only to the subset of the articles. --Zache (talk) 08:03, 16 May 2016 (UTC)[reply]

Another side in this is that the attitude in Finnish Wikipedia towards ip editors is now more relaxed than what it was before FR because now editors doesn't need to stalk continuously changes to be sure that to there is no vandalism. Another thing is that the near real time fixing the broken edits (broken wikicode, adding refs, wikifying text etc) is nice for the user experience too. So FR is not just evil stuff which prevents people from writing to wikipedia but more like that you cannot expect new users be perfect so their edits most likely need to be copy edited. --Zache (talk) 09:15, 16 May 2016 (UTC)[reply]

The problem description of this RfC is actually edited by someone at WMF, but without giving sources for the claims.[1] Note that all the additional claims are not quite right. Then all the previous edits are attributed to another user.[2] I think the edits should be reverted and readded as comments. — Jeblad 17:13, 21 May 2016 (UTC)[reply]

Case German Wikipedia: A success!

This is a pretty one-sided RfC; for convenience, let me first simply quote what I wrote in 2014 on Talk:Flagged Revisions in connection with the Norwegian Wikipedia's request:

As far as I know, Flagged Revisions by now is seen as a full success in the German Wikipedia. The continued use of "sighted versions" after the pilot phase was approved by the community in 2008 in the poll Weiterführung der gesichteten Versionen (and again in another poll in 2010). They are now deeply incorporated in our everyday workflow and the backlog of versions to sight is dealt with in a fairly efficient manner. It really helps fighting vandalism and has taken away quite some stress, I think, as vandalism isn't shown to the public. Probably there are also not as many semi-protections of pages needed as it were the case if we didn't have that feature. Although not directly connected, I also think that the fact that German Wikipedia still allows the creation of new articles by non-logged in (IP) users - as opposed to English WP - may be related to this: Although newly created articles are visible anyway, a generally less stressful fight against vandalism means people also can patrol new articles with less pressure. - So, after the good experience of German Wikipedia's community with sighted versions, I really can't understand why the Norwegian Wikipedia shouldn't be able to use it as well. It's quite ironic what the Wikimedia Foundation is currently doing, isn't it? On the one hand, a feature is activated even if people are strongly opposed (Media Viewer) and on the other hand, if people really want a feature (Flagged Revisions in Norwegian Wikipedia), they're denied its use! So, apparently, the WMF knows always better what's good for the community than the communites themselves? - What I certainly can say is that the anger in the German Wikipedia after the "superprotect" debacle would be nothing compared to the uproar if it were attempted to take the flagged revisions away from them after the community has repeatedly confirmed their use.

Now, I won't deny that even in German-language Wikipedia, there are some vocal critics of Flagged Revisions resp. "Gesichtete Versionen". But I'm also pretty sure that, would de-WP now hold another "Meinungsbild" (poll) on the feature, the approval would be even stronger than the 78,1 % of 2010. As I see it (from German-language Wikipedia experience), Flagged Revisions is one of the most meaningful, successful, and community-accepted features ever introduced, and other wikis that want to adopt it should get every support they need to do so. Gestumblindi (talk) 19:59, 19 May 2016 (UTC)[reply]

Editor count trend

I think that the "Editor count trend" given in the table above might be slightly misleading. For German Wikipedia, it's interpreted as "declining", for English as "stable" - when, in fact, it's not that much different, looking at the actual stats linked from there: German, English.

German Wikipedia: Yearly change of active editors: -4%. New editors: -24%
English Wikipedia: Yearly change of active editors: -3%. New editors: -19%

So, the number of active editors and of new editors is clearly declining in both Wikipedias, but the small difference is enough to interpret it as "stable" for English Wikipedia and not for German? Yearly change in article count is the same for both (+6%), the only bigger differences being the numbers of very active editors and edits per month. But I don't think that counting the raw number of edits is very meaningful, as this may also have to do with different editing approaches... for example, you can make the same change with a dozen small edits, or with a single major edit. In German-language Wikipedia, editors who make too many small edits to an article are often told on their talk page that they should use the preview more often (before saving) in order not to clutter the version history. Gestumblindi (talk) 20:33, 19 May 2016 (UTC)[reply]

My method for checking if userbase was increasing/stable/declining weren't too scientific so if think otherwise than I, then feel free to edit the list. --Zache (talk) 00:33, 20 May 2016 (UTC)[reply]

@Zache: My proposal for making the table a bit more "scientific": Two columns for "active editors" and "new editors"; in both columns, give "stable" for changes of not more than +5% or -5%, "declining" for changes of more than -5% and "rising" for changes of more than +5% - would you agree? Gestumblindi (talk) 10:06, 20 May 2016 (UTC)[reply]

Yes, do it please :) --Zache (talk) 10:13, 20 May 2016 (UTC)[reply]

@Zache: Did it :-). The split into "Active editors" and "New editors" with an assessment for each gives quite different results from the original table. For example, you had categorized Belarusian's editor trend as "rising", but in fact the yearly change of active editors is -6% and new editors -33%, so I have now "declining" in both new columns. Also, I have taken the liberty of removing your conclusions, as it seems to me that the numbers don't clearly support them. For example, you wrote "User base of wiki with the german style confuguration is typically declining", but German, Polish, Hungarian, and Finnish Wikipedia have actually a stable user base (decline in active users not greater than -5%); Hungarian Wikipedia has actually +3% active users and +8% new editors. The number of new editors is apparently declining in most Wikipedias, independent of the setup. Gestumblindi (talk) 22:53, 20 May 2016 (UTC)[reply]

Thank you!. I stand as corrected. However now i look new values i noticed that there is still problems with the trends. If i understand correctly the yearly change values then they are monthly values compared to last year monthly value. Eg (april 2016 vs april 2015.) Problem with that is that the monthly values are fluctuating and it is hard to get trends from single month values. Like if we check values in fiwiki; april 2016 vs april 2015 is decline, but for march 2016 vs march 2015 it would be stable. In longer terms then it would be that all monthly values are higher than what they were at 2014. So if we would like to get reliable trend then it should be made from longer timeframe than one month. --Zache (talk) 08:22, 21 May 2016 (UTC)[reply]

@Zache: Thank you, too! Yes, that would seem reasonable and could help us to get a clearer picture. Maybe you could work out something along the lines of your suggestion? Gestumblindi (talk) 23:45, 22 May 2016 (UTC)[reply]

@Gestumblindi: Lets try.

Numbers in table are (change_in_year/average_number_of_editors_per_month)*100 where
- $change_in_year=last_12_month_average_for_april_2016 - last_12_month_average_for_april_2015)
- $average_number_of_editors_per_month = average(april_2016:april_2015)
- More detailed numbers for copypaste to excel/openoffice can be found here

So numbers are very crude values for that how much number of editors are changed when amount is compared to general size of community.

Colors: background-color is red if change is < -5 ; yellow if change is -5 to 5 ; green if change > 5. --Zache (talk) 10:42, 23 May 2016 (UTC)[reply]

Number of editors change in last 12 month average april 2015 vs april 2016 (%)
	als	ru	de	pl	eo	hu	ar	ia	hi	sq	id	ka	fi	bn	tr	uk	vec	be	en	pt	fa	ce
> 100	7,5	5,7	5,1	2,6	-15,4	11,6	8,6	77,4	3,3	-29	5,3	-3	2,3	37,6	26,1	4,7	16,5	6,2	8,4	8,6	1,4	4,2
>5	-2,6	0,6	-1,7	-0,6	1,6	-4	1,9	16,9	18,9	-18,7	-2,7	13,3	-5,3	24	9,4	1,4	-12,8	5,7	-2,5	-3,6	1	21,3
New wikipedians	11,4	-8,4	-12,8	-6,7	0,8	-5,4	-6,3	99,1	23,2	-30,5	-11,3	14,2	-21,4	19,6	0,1	-9,8	-60,2	25,5	-11,3	-9,4	-6,2	26,4

@Zache: I'm a bit confused, surely it should be > 100 and > 5 (edits), not < 100 and < 5 in the table? ;-) Gestumblindi (talk) 20:41, 23 May 2016 (UTC)[reply]

@Gestumblindi:, of course, fixed it now. --Zache (talk) 09:10, 24 May 2016 (UTC)[reply]

the end of the line ?

According to the statistics above : ruwiki, iawiki, idwiki, trwiki and ukwiki appears to be in a pretty catastrophic situation. Their respective communities don't seems to be able to sustain (or isn't interested in doing so) the constant surveillance effort the extension requires. DarkoNeko (talk) 13:34, 17 June 2016 (UTC)[reply]

My guess is that least ruwiki is using extension in some other way than we are expecting how it should be used (eg. same way than in dewiki). I suspect that because the latest version is always shown the use case is something like that they are using it for marking what has been changed only when needed. However in that case it would be good idea to be able to disable the flagged revs messages which are irrelevant. (In example phab:T135793) --Zache (talk) 07:49, 19 June 2016 (UTC)[reply]

Darkoneko is right. It's irresponsible to enable the extension in new wikis if we don't have a way to disable it where it clearly failed. I propose to forcefully disable it at least on the non-Wikinews wikis where over 10 % of the articles are reviewed and the average review delay is over 100 days: {sq,ar,ce,eo,id,ia,mk,ru,uk,vec}wiki, ruwiktionary, ukwiktionary, ptwikibooks, dewikiquote, ruwikiquote. We could maybe ignore the wikis where $wgFlaggedRevsOverride is false, since one could argue that there is no real damage apart from interface clutter and ugly banners/messaging to users: so the list would be {sq,ar,id,mk}wiki, ruwiktionary, ukwiktionary, ruwikiquote.

Then each community can reconsider the functionality and ask for it again following the steps at Flagged Revisions#Enabling and Flagged Revisions#Local. Then, once the situation is stable, we could consider new wikis. Nemo 09:12, 19 March 2017 (UTC)[reply]

Different wikis use flaggedrevs differently. Folks here on meta who are not members of those communities are patently unqualified to pass judgement on how those communities are choosing to use it and whether it is working out to their satisfaction. --Pi zero (talk) 00:03, 20 March 2017 (UTC)[reply]

But when a wiki doesn't even bother considering whether the system is satisfactory for them, then someone else has to. And if nobody does, let's not propagate the error. Nemo 10:34, 20 March 2017 (UTC)[reply]

Seems (tbh) arrogant for an outsider to sit in judgement of whether inaction by a local community is choice or neglect; it amounts to "leave it to local discretion unless I don't approve of the way things are going there". (I'm reminded of Tom Lehrer's "They've got to be protected, all their rights respected, till somebody we like can be elected!") --Pi zero (talk) 16:02, 22 March 2017 (UTC)[reply]

Some of the wikis where the extension does not work I'm tempted to say the extension is misconfigurated. I wrote about this extension a long time ago, and said what would work and what would not, but it was somewhat difficult to be heard. Error detection has to do with such things as probability of detection, which drops if the changes are hidden from view. Readers must see the versions to be able to fix them, but they must be told what they see. If it is unpatrolled (unreviewed) then tell them so. — Jeblad 18:27, 13 April 2017 (UTC)[reply]

+------+---------+-----------+---------+
| year | wiki    | reviewers | reviews |
+------+---------+-----------+---------+
| 2017 | dewiki  |      4388 |  188574 |
| 2017 | ruwiki  |      1143 |  132167 |
| 2017 | plwiki  |      1061 |   65660 |
| 2017 | ukwiki  |       263 |   37643 |
| 2017 | trwiki  |       187 |   28941 |
| 2017 | fiwiki  |       204 |   23178 |
| 2017 | arwiki  |       274 |   17038 |
| 2017 | huwiki  |       128 |   16569 |
| 2017 | enwiki  |       706 |   13490 |
| 2017 | idwiki  |       100 |   11109 |
+------+---------+-----------+---------+

And i would still argue that different wikis are using the extension even when the pending lag times are bad, but not how we are expecting them to do. In example ruwiki is doing lot of reviews (query) and they have also bot which stabilizes the visible pages. logs) so they are clearly using FR even though the pending lag times are horrible (or irrelevant for them). --Zache (talk) 20:40, 15 April 2017 (UTC)[reply]

@Nemo bis: and yes. It would be good idea to least to ask if wikis which doesn't seem to use FR would they like to disable it or do they need some help. Eg. [[3]], ce, sq, eo, id ... In IA correct solution would be just to disable the FR because it is not in use, but in EA correct solution if they want to use FR is tech support because it seems that there is lot of pending bot edited articles from moving the language links to wikidata. --Zache (talk) 21:24, 15 April 2017 (UTC)[reply]

Maybe it's the time to archive it

As nowadays archiving an extension can be somewhat easy, and only rare Phab tasks are resolved in recently ~2 years, maybe we can say a fair "good bye FlaggedRevs" in favor of mw:ORES deploying. --Liuxinyu970226 (talk) 08:02, 30 October 2017 (UTC)[reply]

We are using both ORES and flaggedrevs in fiwiki. They are doing different things and not alternatives. --Zache (talk) 08:15, 30 October 2017 (UTC)[reply]

FlaggedRevs can be used to generate training sets for ORES, and ORES can be used for some obvious vandalism, but other than that they don't have much in common. — Jeblad 10:06, 22 November 2017 (UTC)[reply]

arz Wikipedia needs it

The Egyptian Arabic Wikipedia really needs this flagged/last reviewed edit.

The Egyptian Arabic Wikipedia suffers from consistently deliberate vandalism. The main reasons are that many people believe in conspiracy theories that this wiki aims at dividing "Arabs" or that we shouldn't write with any Arabic dialect other than that of the Quran.
Since very few have time or capacity to review articles that have been edited, especially by anonymous users, it is wise to choose to display the last approved version of articles, because I noticed that there are many articles that were vandalized and left for too long!
Anonymous or mostly-inactive users are very unlikely to contribute significantly positively, so it's better to have more possibly less complete articles that more possibly vandalized ones, which is unfortunately the case!
The case of this wiki is very different from the others that don't suffer from conspiracy theories based vandalism.

The point is, it's very inappropriate to leave the wiki with clearly vandalized and shortened versions of the articles. Thanks. --Mahmudmasri (talk) 19:08, 22 March 2018 (UTC)[reply]

Urdu Wikipedia

Hi all.

I am one of the admins of Urdu Wikipedia. At present there is a request for reviewer rights on Urdu Wikipedia.

The appeal is put on hold because of discussions.

I request granting of this right for the betterment of Urdu Wikipedia editing community. --Muzammil (talk) 22:03, 16 June 2016 (UTC)[reply]

Which problems do exists with FR and how can they be counteracted?

To make this RfC move forward into something useful I believe one option could be to identify problems with the extension and find solutions to those problems.

Automation for expected classification; can ORES be used to preset the expected flags? (phab:T132901)
Allow ordinary users to tag edits for review; by tagging edits for review it isn't necessary to review all changes in a namespace (phab:T72458)
Aggregation of weak classification; if enough users reads a specific version without complaining, should that lead to an automated classification?
Throttling of automated classification given amount of pending edits; if enough pending edits exists, should the willingness to set an automated classification increase? (phab:T72457, phab:T72456)

I guess there are a lot of additional points that can be added. — Jeblad 09:49, 2 October 2016 (UTC)[reply]

This is my list

Set hard time limit for stabilization. If pending changes are older than 30 days then show latest version of the page. (30 days because it is default length of the recent changes feed)
Counter vandalism backend and so tools also are generally using the patrol flag (in example ORES filters, RTRC, EventStreams, RCStream etc). Partial solution for this is to enable patrolling in wikis which are using Flagged revs so that FR reviews are propagated to patrol flags too and hide patrolling stuff from UI. (phab:T144817). However when the revision is patrolled manually it doesn't become approved in FR and in fiwiki this approving is made using bot. However it is clear that approve made using patrol tool should be propagated automatically to flagged revs approve too.
Some of the special:ValiadationStatistics pages silently fails to update. In example huwikis and plwikis The average wait for edits by users that have not logged in and The median wait for edits by users that have not logged in are same as in 23.5.2016 when i compiled the stats tables. phab:T163107
In mobile wikipedia the latest or stable versions is shown depending the settings, but there is no indication which version. There is no method to switch between them, In history list there is no review status information.
If non-autoreviewed user makes lot of edits, like bot without bot-flag, it will choke the review queues. After that in the reviewed queue will start to aggregate new changes from autoreviewed users too which makes the reviewing harder. Solution for this would be some kind mass approve for the changes but currently there is none. In finnish wikipedia this is handled currently using the bot which once per hour approves edits which are patrolled OR from whitelisted IP:s OR from user with autoreview-user right (bots, editors, autoreviewers etc) so when then autoreview right is added to user bot will approve those edits.

(edited my comments to list too) --Zache (talk) 06:14, 16 April 2017 (UTC)[reply]

Enwiki's deferred changes RfC

Just for FYI. Enwiki opened RfC for extending their deferred changes usage so that the ORES/bots/Abuse Filter could tag the article change so that article would be reviewed via Flagged revs. In discussion there is scenario where article would be temporarily stabilized so that if there is most likely bad edit then latest stable version is shown to readers by default until the change is reviewed. --Zache (talk) 10:02, 30 October 2016 (UTC)[reply]

Compelling use case

Dereckson: If we want to continue to use this extension, we can devise together a workflow and conditions to deploy it, at least ask them systematically a compelling use case...

Use case

Better review workflow than with patrolling
Flagged revs supports the patrolled flag when patrolling is enabled (used by mediawiki API, ORES, RCFeed ...)
if autoreview/editor user rights are managed manually then it can be used as accurate list of "trusted users" for ORES
- and other way too. system can suggest user to be promoted to autoreview or editor user group based on how ORES scores his/her edits
automatic (short) stabilization of the pages if edit looks like vandalism based on ORES scores OR abuse filter etc.
automatic (short) stabilization of very visible pages. In example if page is linked from front page it will be stabilized

Reference setup

enwiki's protection setup with limited number of articles is good reference setup

Process and conditions

Nowikis similar protection setup. Community is stable and it is using patrolling so it is known that it can handle the workload. Nowiki also have coders and bot operators which can support reviewing with bots if it is needed. If nowikis setup goes forward then it can be used as reference process for enabling the FR.

--Zache (talk) 07:51, 16 April 2017 (UTC)[reply]

Wien hackaton

Wien hackaton is 19 – 21 May 2017 and most likely it is place to meet relevant people from WMF and Countervandalism_Network and ask them what is the actual plan with FR if there is some. If nowiki ticket phab:T66726 is still dead in the water it is also good place for disucssing about that too. So that would be time and place to push things forward if there is interest do some kind FR meeting there. --Zache (talk) 07:51, 16 April 2017 (UTC)[reply]

Ok, i made the proposal Phab:T163197 - Flagged revisions discussion: Current state and future plans. Feel free to edit the ticket. (FYI: @Jdforrester (WMF):, @Dereckson:}, @Atlasowa:, @Jeblad:, @Nemo bis:) --Zache (talk) 11:13, 18 April 2017 (UTC)[reply]

Thanks. --Zache (talk) 19:26, 29 April 2018 (UTC)[reply]

Request from Azerbaijani wikipedia

Hello, I'm an admin from Azerbaijani Wikipedia. Is it possible to open this sytem for our wikipedia?--Azerifactory (talk) 15:22, 10 May 2018 (UTC)[reply]

Hello @Azerifactory:} please see this section --Alaa :)..! 15:52, 10 May 2018 (UTC)[reply]

Hi, @علاء:, I've read it but how I can contact the phabricator? --Azerifactory (talk) 20:55, 10 May 2018 (UTC)[reply]

@Azerifactory: login through [4] and see Phabricator --Alaa :)..! 20:57, 10 May 2018 (UTC)[reply]