Requests for comment/Flagged revisions should display latest versions

The following request for comments is closed. Out of scope for a global RfC, need to be discussed at each individual project. --Martin Urbanec (talk) 16:17, 27 December 2020 (UTC)[reply]

This is a proposal that most wikis with Flagged Revisions (FR) should display the latest (unreviewed/unpatrolled) versions, instead of the stable (reviewed/patrolled) versions. This will improve article quality, community health, editor retention, and make the wikis much better overall.

There are currently 9 Wikipedias, mostly of SE European languages, where this is an issue, and improvements can be done:

Arabic, Albanian, Bosnian, Macedonian, Turkish, Georgian, Hungarian, Indonesian, Classical Chinese

I have not found this to be an issue on any of the non-Wikipedia sister projects, so I will just discuss Wikipedia here.

Background[edit]

Here I will focus just on the Wikipedias, since the sister projects almost all display the latest rather than stable versions. I have carefully reviewed each and every FR Wikipedia, and have found that there are currently 9 Wikipedias could make a few tweaks to their FR system in order to improve community health, editor retention, and make sure article quality is up-to-date. FR is very difficult to configure, and is very difficult to remove, so the current issues that these 9 Wikipedias have can be done by making a stable to latest version default page display change.

Since this requires discussion and coordination from multiple wikis, it is better to coordinate and discuss this on Meta rather than separately within the multiple local wiki communities.

First of all, this proposal excludes the German and Polish Wikipedias and other Wikimedia sister projects. Those are flagged revision wikis using stable versions that are doing very well, with short reviewing times and autopromotion of moderately experienced users.

Why this is a problem on certain wikis[edit]

However, the rest of the Wikipedias that use FR displaying stable versions have backlogs that can go for weeks, months, and even years without even being reviewed by anyone. This means that if a moderately experienced user is updating statistics on hundreds of geographical stubs and correcting formatting, many of these helpful edits will be ignored and undisplayed for very long periods of time. The wikis essentially become stuck in time, with non-popular topics outdated and neglected.

Unlike the German Wikipedia, they have very few editors who can review unpatrolled edits (a permission much easier to get in German WP). None of these wikis autopromote users as on the German Wikipedia, where users with 200+ edits and certain other requirements are automatically approved by the system. These Wikipedias are all SE European languages, plus Arabic and Indonesian and Classical Chinese:

Arabic, Albanian, Bosnian, Macedonian, Turkish, Georgian, Hungarian, Indonesian, Classical Chinese

The WMF probably is not very much aware of these issues, since they are focused on the big projects that everyone pays attention to, like English and German Wikipedias.

Proposal[edit]

The proposal is that if a wiki community is not actively reviewing enough unreviewed edits, the latest version should automatically be shown by default to all viewers. This is already the model used by the Russian Wikipedia, and it is working very well. The purpose of the FR system on the Russian Wikipedia is more like English Wikibooks, where message shows up on the top of the page to remind a reviewer to simply check if the most recent edits, already displayed to all users by default, has any problems or not.

These are the 9 Wikipedias that use flagged revisions, display stable (non-latest) versions, and with long backlogs where helpful edits can often be ignored for weeks/months/years.

Arabic, Albanian, Bosnian, Macedonian, Turkish, Georgian, Hungarian, Indonesian, Classical Chinese

Which wikis to start off with[edit]

For Classical Chinese, it is not much of an issue because there is very little activity in the community. Arabic, Indonesian, and Turkish are large communities and lots of problematic edits site-wide, so we would need a lot of time to talk over proposed FR changes.

These are the 6 smaller Wikipedias that we can start off with. They are smaller Wikipedias with not much vandalism, because they are all local languages that do not attract big crowds of vandals.

Albanian, Bosnian, Macedonian, Georgian, Hungarian, Classical Chinese

Bringing the most active admins together on here to discuss would be a good idea.

Alternative solutions to tweaking FR[edit]

It is likely that none of them (Albanian, Bosnian, Macedonian, Georgian, Hungarian, Classical Chinese Wikipedias) have issues that require site-wide FR on all articles, with only stable versions displayed. Some of the alternative solutions to common issues that they can use instead:

Casual vandalism: The Portuguese Wikipedia has shown us that casual vandalism, most of which are from IP addresses and sometimes brand-new registered users, can be effectively combatted by requiring all editors to have registered accounts.
POV issues: Deploy only on selected articles, as with the English Wikipedia.

Site-wide FR is only necessary if there is systematic long-term POV edit warring and long-term vandalism, like state-sponsored attempts to rewrite the entire encyclopedia, that would affect a very large proportion of articles. This is likely to be a relatively rare phenomenon.

Types of flagged revision Wikipedias[edit]

Stable version displayed, long backlog[edit]

These are the Wikipedias with flagged revisions that display only the stable (reviewed/patrolled) versions. These are the 9 Wikipedias that would do far better if the latest instead of stable versions are displayed.

The rest of the wikis below are all doing fine.

Stable version displayed, short backlog[edit]

These Wikipedias with stable versions are working very well. Most people in the community are happy with the way the FR system is working, and backlogs are very short. Autopromoting of experienced users is done by the system.

Latest version displayed[edit]

These are Wikipedias that display the latest (unreviwed/unpatrolled) version. Russian, Ukrainian, Belarusian, and Chechen have long backlogs that can be unattended for years, but at least the latest version still shows up. The international auxiliary language Wikipedias, and Finnish and Alemannic, are also doing well.

Russian
Ukrainian
Belarusian
Chechen
Esperanto
Interlingua
Finnish
Alemannic
Venetian (does not use color highlighting)

If a non-autopatrolled user makes an edit, a message shows up on the top of the page to remind a reviewer to simply check if the most recent edit, already displayed to all users by default, has any problems or not.

Pending changes on a few selected articles[edit]

English Wikipedia style, deployed only on a few articles that are prone to long-term POV edit warring and vandalism. This is generally working quite well.

Table by Zache[edit]

For reference, here is a table compiled by Zache in November 2020 (there is also an older 2016 version at Requests for comment/Flagged revisions deployment). It has most, but not all of the FR Wikipedias. Some FR Wikipedias not included are Bosnian, Macedonian, and Classical Chinese.


	Project	FR installation year	Which article version is shown	Target articles	Autopromote	Pending queue length 2020/11	Pending queue length % 2020/11	PendingLag average 2020/11
	Alemannic	2008	latest	all	no	1	0 %	0.3 days
	Russian	2008	latest	all	no	323705	20.1 %	723.2 days
	German	2008	stable	all	yes	7754	0.3 %	11.5 days
	Polish	2008	stable	all	yes	3911	0.3 %	9.1 days
	Esperanto	2008	latest	all	yes	1257	0.5 %	86.1 days
	Hungarian	2008	stable	all	no	3636	0.8 %	13.6 days
!	Classical Chinese	2008	stable	all 38% of articles reviewed	no ?	1085	26.8 %	626.4 days
	Arabic	2009	stable	all	no	4994	0.5 %	15.8 days
	Interlingua	2009	latest	all	no	3197	69.9 %	1404.3 days
	Hindi	2010	latest	protected	no	52		101.6 days
!	Albanian	2010	stable	all	yes	1029	1.1 %	47.7 days
!	Indonesian	2010	stable	all	no	39441	8.8 %	538.4 days
	Macedonian	2010	?	all	yes (???)	67	0.1 %	1.6 days
	Bosnian	2010	stable	all	no	162	0.2 %	70.4 days
	Georgian	2011	stable	all	no	206	0.2 %	83.8 days
	Finnish	2011	latest	all	no	1132	0.2 %	11.8 days
	Bengali	2011	latest	protected	no	4		2.3 days
	Turkish	2011	stable	all	yes?	2236	0.6 %	11.5 days
	Ukrainian	2011	latest	all	no	78300	8.7 %	281.7 days
	Venetian	2011	latest	all	no	72	0.1%	80.8 days
	Belarusian	2011	latest	all	no	7888	4.3 %	598.6 days
	English	2012	latest	protected	no	13		0.1 days
	Portuguese	2013	latest	protected	no	???
	Persian	2013	latest	protected	no	12		1.9 days
	Chechen	2013	latest	all	no	1204	0.4 %	1119.4 days

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 2020/11 average pending queque length between 2020-11-01 and 2020-11-30 from flaggedrevs_statistics database table
Pending queue length % 2020/11 Pending queue length 2020/11 average pending queque length between 2020-11-01 and 2020-11-30 as % of all articles in the scope from flaggedrevs_statistics database table
PendingLag average 2020/11 average pending lag between 2020-11-01 and 2020-11-30 from flaggedrevs_statistics database table

Wikis marked with !: These wikis have stable version by default and very long backlog

Wikis with long backlog: Green rows are wikis where the backlog is long. These are mostly Russian Wikipedia style configurations where changes to all articles are tracked and latest version of the article is visible by default.

Wikis with short backlog: Blue rows are wikis where changes to all articles are tracked and changes are checked in orderly manner so that backlog doesn't grow. All but three of the installations are German Wikipedia style configurations so that the stable version of the article is displayed by default.

Protection setup: Yellow rows are English Wikipedia style configurations where only changes to selected articles are tracked. Stable version of the selected article is displayed by default.

Final words[edit]

Thank you for taking the time to read all this. I am looking forward to discuss this further. Voltairacus (talk) 20:48, 6 December 2020 (UTC)[reply]

Discussion[edit]

Oppose. The main reason why we at bs.wiki opted for Flagged Revisions was so that we could have ample time to review and approve edits given how small our community is. The way the system is set-up right now essentially discourages vandalism as it will not show up by default to unregistered users, i.e. most of Wikipedia's readers. I don't see how this would improve article quality – in fact, I think it would do the opposite as people would be more likely to vandalize the wiki, and the already small community would have to work ever harder to deal with that. When it comes to the backlong, in most cases only edits where a substantial amount of content was added or removed (usually w.r.t. a controversial topic) have to wait a little longer than usual to get reviewed, and the stable version is seldom out of date (or "stuck in time", as you put it). – Srđan (talk) 21:26, 6 December 2020 (UTC)[reply]
- Comment Thank you for this thoughtful response. This proposal is only a suggestion, and community consensus needs to be done on a case by case basis. If long backlogs are not an issue at bs.wiki and you feel that the current system is working, then I support you. I am waiting to hear what community members from the other 8 Wikipedias have to say. Voltairacus (talk) 21:32, 6 December 2020 (UTC)[reply]
Oppose. As per Srđan. The system for Bosnian Wikipedia works. The backlog will be solved eventually. --Mhare (talk) 22:33, 6 December 2020 (UTC)[reply]
Comment hu.wp has just decided about restoring flagged revisions in a vote, following a test period during which ~~FR was effectively turned off.~~ the latest version was shown to readers. The description is not in English, but give machine translation a go. - Xbspiro (talk) 01:02, 7 December 2020 (UTC) - clarification: Xbspiro (talk) 13:07, 7 December 2020 (UTC)[reply]
- Comment I would also count huwiki as one of the wikis where the Flagged revs is working. I am not sure if huwiki's method of using is stable in the long term as the backlog is increasing, but it is clearly managed and should be in same group than dewiki and plwiki. --Zache (talk) 01:37, 7 December 2020 (UTC)[reply]
  - Comment You're right, FR is in use on hu.wp, during the test they have just chosen to show the latest version instead of the last stable one. The test started in April 2018 and the test settings are still in effect, afaict. Feed the vote's summary to a machine translator service, it pretty much sums up what happened. - Xbspiro (talk) 13:07, 7 December 2020 (UTC)[reply]
Comment As for my table, the columns 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 was affected by bug phab:T163107 and are heavily broken in Special:ValidationStatistics page for half of the wikis. Numbers should be updated before the use. I can help with this. Second thing: There is report of Hungarian wikipedias test how the change of the settings from stable to latest revivision by default effected in english by @Tgr:: Hungarian Wikipedia FlaggedRevs test, october 2019 (in short: showing latest revision by default ( setting $wgFlaggedRevsOverride = false ) increases the number of edits made by IPs by 30% and the overall vandalism minimally increases (2-3%) compared to showing approved revisions by default.) --Zache (talk) 01:23, 7 December 2020 (UTC) Edited my own comment as the data in the table is now fixed. --15:17, 7 December 2020 (UTC)[reply]

@Zache: I think there is a misunderstanding how "minimal" vandalism grew during the test. ORES numbers shows there was 1000 vandalism in average/month before the test and there was a +500 during (1500 in average/month, so it is 50% not 2-3% !) These numbers is omitted from the English version of the report. If patrollers need to deal with those too, less time remain to review deeper for largers edits... JSoos (talk) 02:11, 9 December 2020 (UTC)[reply]

@JSoos: Yes, we mean different things here. I thought those numbers as if the good/bad edit ratio stays the same when the total number of edits grows then the increase is ok, but if the number of bad edits increases faster than good edits then it is not ok. However, I can see your point that if the number of active reviewers will not increase at the same time then an increase of the (anonymous) edits means either a lot more work for the existing group of reviewers which likely is not possible OR the quality of the reviews will go down as they have less time per review because all the time goes just to keep up with the backlog. --Zache (talk) 12:26, 9 December 2020 (UTC)[reply]

Comment I'm an active member of the huwiki community. We recently had a vote on this, and I voted for the option to display the latest version, regardless of revision status. That said, my side did not prevail, the result of the vote was to display the most recent stable version instead, and I would take a very dim view of any attempt to subvert the community's decision. I strongly suggest that huwiki be excluded from the scope of this proposal. --Malatinszky (talk) 19:25, 8 December 2020 (UTC)[reply]
- Comment In my opinnion realistic scope for this proposal would be Indonesian Wikipedia and Classical Chinese Wikipedia where both have stable by default, no autopromote and so long backlog that it is not expected to be cleared if there is no change to something. However, i am not sure if anybody have told to Indonesian and Classical Chinese Wikipedia or any other wikipedia communities that we are talking on their flagged revs settings and somebody should do that. --Zache (talk) 21:38, 8 December 2020 (UTC)[reply]
Comment About on the "Table by Zache", I updated the colors and legend to be more exact as the table was named after me. However, I keeped the short backlog=blue, long backlog=green but removed the Russian/German style from labels as it was not exact. Fiwiki uses ruwiki style configuration and sqwiki (albanian) is using dewiki style configuration and the configuration itself doesn't tell if the backlog is short or long. --Zache (talk) 22:43, 8 December 2020 (UTC)[reply]
Oppose In huwiki there was a 2.5 year long experiment (still on) when latest version was shown, expecting more users will register as editors, so number of regular editors will grow. The statistics shown now growth, but some more vandalism was experienced. There was a community voting, to revert the settings to show the stable version again. I think it is the community who should discuss what is better for them, not outsiders. However long backlogs is possible, and patrolling tools would help a lot, but because few community use FR, there are almost no technical help in the topic. Eg. even our request for reverting to stable version after experiment is there without help. JSoos (talk) 01:59, 9 December 2020 (UTC)[reply]

Comment Nobody "officially" let us (the huwiki community) know about this discussion, only by accident I was possible to know about it, which is a bit annoying! JSoos (talk) 02:18, 9 December 2020 (UTC)[reply]

Comment I have officially notified everyone on the village pumps or embassies of all 9 Wikipedias now. Voltairacus (talk) 08:13, 9 December 2020 (UTC)[reply]

Oppose On huwiki. Recently we had a vote, which resulted in "show the stable, flagged version". There was a long experiment before with "show the latest version of the articles", but according to most editors on huwiki, it was not a good solution. So, please switch back the "show the stable, flagged version". Misibacsi (talk) 11:04, 9 December 2020 (UTC)[reply]

Comment I don't dispute that there is a problem here, I just don't see why the global community has a place here. You make a compelling case, but that case would be best decided on and viewed by the local wikis rather than on Meta. Zoozaz1 (talk) 20:24, 9 December 2020 (UTC)[reply]

Oppose sorry to say, but you can't open a discussion on Meta to make technical change that will affect Large projects in this way, as Requests for comment used for "global issues or for other projects"! I'll talk here about Arabic Wikipedia, you put only a notice on the embassy page about this proposal that will affect the project heavily, as you'd at least put another notice on the community village pump! Also, a lot of user will like to comment, but they can't read/write in English; it deprived users of the right to participate in discussions that affect their projects. Plus arwiki community discussed this topic several times throughout the years, and the community want the stable version to be display, not the last version, so even if a lot of users accept this proposal, no one can force Arabic Wikipedia community to accept it. Every community has freedom of choice, and the right to discuss in its own language --Alaa :)..! 20:36, 9 December 2020 (UTC)[reply]

Oppose. Thanks for your proposal. I understand your goodwill, however FR with stable version shown has been a good method to show the articles' versions with certain quality, for the purpose to attract more readers to become contributors in small wikis. Also, FR would provide a better quality assurance of the administrative works in small wikis. With the FR with stable version shown in the last decade, the lzh wiki would run in a smooth condition and new active contributors come from time to time. Thus remains change would be a better proposal if there is no big wrong in reality. Thanks again for your kindly suggestion. --Itsmine (talk) 07:38, 10 December 2020 (UTC)[reply]

Comment also for alternative proposals. In fiwiki our strategy has been that there is a pretty low threshold for giving autoreview permissions, but as this is done manually it is substantially higher than in dewiki in the example. With reviewer permissions, the difference is even more visible. Also as @JSoos: explained, the problem with this is that incoming anonymous edits will be a problem if those aren't limited somehow. An example showing a stable version by default guides towards editing with accounts which reduces the need for reviewing as users can be flagged as autoreviewed. Fiwiki shows the latest by default and backlog would have been drowned to anonymous edits if nothing have been done. Fiwikis solution has been automatic reviews by bot. Most uncontroversial rules for approving edits have been autoreview the selected ip-addresses and retroactively review the pending changes of users who have been added to autoreviewed, editor or bot user groups after the edits. More controversial rules have been approving by ORES-score and different minor changes detections as the bot is stupid as brick and doesn't really understand what has been changed. Anyway, if some community wants to use autoreviewing bot then I could try to run it on other wiki's too. I think that just autoreviewing the selected IP addresses and retroactively reviewing the pending changes of users who have flagged as autoreviewed will solve some backlog problems even if all other rules are left out (Fiwiki uses bots PendingChangesBot for autoreviewing and stabilizerbot for 24h stablizations of the pages after problematic edits) --Zache (talk) 11:28, 10 December 2020 (UTC)[reply]

Oppose on huwiki. Although being rather inactive recently, my experience is, as a patroller, that minor edits are approved almost immediately, while larger ones often remain unchecked for weeks, maybe for months (space for improvement?), but these are more likely in need of editing, those - at first glance -, looking okay are generally approved within days by one of our 200 patrollers. I think some filtering must be done before having the new edits instantly seen by readers. Csuja (talk) 16:43, 10 December 2020 (UTC)[reply]
Comment Changing FlagRev state has a high impact on the wiki in terms of user experience, patroller workload and public relations. I don't think that decision can be reasonably centralized. Given FlagRev is an old feature and doesn't get much support, it would make more sense to focus on pooling resources between the wikis that use it and collaborate insights and statistics (that was the motivation behind making sure that huwiki's FlagRev experiment is available in English) and tooling, rather than trying to have some kind of centralized decision. Meta RfCs are not good channels for trying to convince individual wiki communities. --Tgr (talk) 07:58, 11 December 2020 (UTC)[reply]
Oppose for such a sweeping change and such different use cases on the few wikis that use this, this should be discussed locally on each wiki. --Rs chen 7754 04:16, 12 December 2020 (UTC)[reply]
Comment Are there dedicated project pages that users can go ask for help if they have questions about their edits not being approved for, say, 1-3 weeks or more? Or will they still have to post one by one on the talk pages of admins and reviews? Voltairacus (talk) 20:51, 18 December 2020 (UTC)[reply]

In Huwiki, Patrollers has a Noticeboard where such warnings/help can be posted. JSoos (talk) 09:36, 22 December 2020 (UTC)[reply]