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

https://gerrit.wikimedia.org/r/190656

Patch-For-Review

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

https://gerrit.wikimedia.org/r/190656

Patch-For-Review

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.

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 commons.wikimedia.org, nl.wikipedia.org, 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 en.wikipedia.org 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.