Recent changes patrolling limited to tagged changes
Closed, ResolvedPublic


This is a request for a form of recent changes patrolling where only tagged changes would be marked as needing patrolled (outside new pages), as I suggested in T20670. This would be useful to determine if a tagged change has been dealt with or not, which cannot be achieved with the current implementation when RC patrolling is disabled. The native mediawiki patrolling feature seems to fit very well for this use - from a diff one can mark a change as patrolled and rollbacking marks a change as patrolled.

I've uploaded a patch that implements this. This requires RC patrolling enabled, then enabling tag patrolling limits RC patrol to tagged changes. A list of tags to ignore can be defined in the config, typically tags applied for information or research purposes (e.g. HHVM, visualeditor), not anti-vandalism.

Related Objects

Cenarium created this task.Feb 14 2015, 4:11 PM
Cenarium updated the task description. (Show Details)
Cenarium raised the priority of this task from to Needs Triage.
Cenarium added a subscriber: Cenarium.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 14 2015, 4:11 PM
Cenarium claimed this task.Feb 14 2015, 4:12 PM
gerritbot added a subscriber: gerritbot.

Change 190656 had a related patch set uploaded (by Cenarium):
[WIP] Tagged recent changes patrolling


Change 190656 had a related patch set uploaded (by Cenarium):
Tagged recent changes patrolling


Cenarium triaged this task as Normal priority.Feb 15 2015, 5:48 PM
Cenarium set Security to None.
Cenarium renamed this task from Tagging-based recent changes patrolling to Recent changes patrolling limited to tagged changes.Feb 26 2015, 1:04 AM

There's unanimous support for this feature at enwiki, see original request for pages expanded from redirects and follow up on this specific implementation. I'll restart development of the patch but we need to urgently tackle the performance issues I mentioned in T91535.

Krinkle added a subscriber: Krinkle.EditedMar 26 2015, 7:01 PM

I'm curious why one wouldn't just enable RC patrolling regularly and use filters in the user interface to control what "todo" items one is interested in.

I'm aware this has been discussed many times to no end, but excuse my honesty when I say it seems hypocritical not to enable on enwiki. With tools like Huggle, STiki, and others; enwiki is clearly interested in patrolling recent changes in general.

Whether we can actually patrol everything is irrelevant. What matters is that one can keep track of what has already been patrolled, centrally. This way Huggle and STiki don't have to cripple themselves by maintaining their own "rcpatrol" database. Likewise, tools written for wikis that do have RC patrol enabled (such as,, and about a 100 others) currently don't work on enwiki because of this. E.g. tools tools like LivePatrol, LiveRC, and RTRC; don't work on as there, users can't mark a change as patrolled (after they assessed it as good, or bad-but-dealt-with).

If sysops are freaked out by the red ! marks in RecentChanges and Watchlists and prefer not to have it, it can trivially be hidden with CSS (could even be done by default via MediaWiki:Group-sysop.css). Or if they so desire, they could revoke the patrol right from sysops and opt-in via membership of existing reviewers and/or rollbackers user groups on enwiki. Besides, this is already the case for new pages now.

The advantage of enabling:

  • Huggle and STiki don't need their own database.
  • Tools based on the MediaWiki API (RTRC) will start working.
  • All of the above will collaborate from the same queue behind the scenes (without any visual change).
  • We don't need to develop a partial RC patrol based on tags.
  • Users can patrol how and what they like based on tags, users, namespace, edit count, whatever they want, it can be done from within a tool. And by default Special:RecentChanges will provide at least namespace, anon/logged-in/bot and tags as filters for creating lists of unpatrolled changes.

That's something I had considered, however, as you noted, on wikis with a high volume of editing like enwiki, the large majority of edits would remain unpatrolled, so showing patrol marks for all of those would be more of a distraction. The patrol feature would be relatively little used directly, hence the narrowing down to tagged changes done here. (I think one of the main reasons RC patrol was removed was that it was little used.) We could reduce the number of unpatrolled edits with a usergroup of 'whitelisted' users but we would need a separate userright from "full" autopatrol, since a usergroup of autopatrolled users exists already but for new pages creation, which requires a more specialized level of trust. The disadvantage is that it would generate a lot of automated patrol log entries, I've read somewhere that it was an issue though that might be outdated information.

It is true we don't have to patrol everything. However, in that case we should also not provide the option to filter out unpatrolled edits in general (which would be of little use). And if we were to completely hide these patrol marks via css, we wouldn't be able to visually differentiate between patrolled and unpatrolled edits when filtering for a tag where it makes sense. So we need this implemented in core and to show the patrol marks in this case (and provide the option to filter out unpatrolled edits). It wouldn't make sense to do so for certain tags, e.g. HHVM, visual editor, so we still need a list of tags defined as important, i.e. indicating a problem, also needed for T91425. So basically this amounts to going back to a restriction on RC patrol, as in one of my earlier patch set. I don't mind whether we enable full RC patrol or not, as long as we hide the user interface when it doesn't make sense (and only then), i.e. have a config variable for a "minimalist RC patrol interface". I guess it's something that enwiki could accept.

Okay, I've uploaded a patch set for T91535.

For this request, I think we should simply implement a config variable that minimizes the RC patrol interface. (The patrol marks are shown only when filtering recent changes for a problem tag, and the patrol action link is only provided on a diff when the associated RC item is unpatrolled and tagged with a problem tag.)

Concerning a list of 'whitelisted' users, I think we should do this on the "source", so with regard to tags, have a userright 'autotags-exempt' that does not autotag the RC item for users with this right (so this should be implemented in the patch set for autotags). This has the advantage of not creating that many automatic patrols.

So we enable RC patrol, as you requested, in a way that is barely visible, i.e. it works behind the scene. The consensus found in the discussions linked above is sufficient to do this on enwiki, since such a partial implementation of RC patrol is necessary to implement the request.

We should probably make the minimalist UI into a preference option available when RC patrol is enabled.
The config variable for it would just determine the default. It could be called $wgUseFullRCPatrolUI (true by default).

I wonder if we shouldn't propose to enable RC patrol by default with minimalist UI (i.e. $wgUseFullRCPatrolUI set to false) on all WMF projects. (Those projects already using it would have to override this last setting.)

I've updated the patch set for this and uploaded a patch set for T73236. I don't plan on implementing the pref option or exemption system yet.

I noticed there's a configuration setting that can disable logging of autopatrol actions, so this shouldn't be an issue.

Cenarium closed this task as Resolved.Feb 9 2017, 5:07 AM

I think we absolutely need a form of patrol intermediary between NPP and RCP.
But tags can't be the solution, though they may be part of the solution.
We should check if an edit is worth being shown as needing patrol from a variety of sources, including: problem tags (as this task suggested) , but also ORES and AbuseFilter, and bots via the API.
Problem is how do we store this data? It would be nice for the patrol flag to have three states: -1 for "needs patrol", 0 for "not patrolled", +1 for "patrolled". Unfortunately, rc_patrolled is unsigned in the rc table, so we would need a schema change.
I'll make a task for selective patrol in a short while.