Page MenuHomePhabricator

Explore process for turning on RCPatrol for English and other relevant wikis
Open, HighPublic

Description

Being able to tell which edits have been patrolled is essential for making the edit-review, anti-vandalism and other processes more efficient. Being able to do so will stop edit-reviewers and vandalism fighters from stepping on each others' toes and enable on-the-fly generation of backlogs, among other benefits.

MediaWiki has a system for this already (RCPatrol), but some years back different communities decided to turn off this feature (for all but more advanced users). In English, my understanding is that some users objected to how the flag is displayed on RecentChanges (with a !).

As a first step towards addressing this issue, let's do some research so we understand fully:

  • Which wikis this affects.
  • What the objections were and whether they remain relevant.
  • What remediations might overcome any remaining objections.
  • What a path forward for this might look like.

What do we know

  • Wikis with Flagged revisions will have validated revisions marked as patrolled automatically.

Conclusions and notes (March 2017)

Definitions:

  • RCPatrol (patrol-flag) is disabled on most WMF wikis (except for 94 wikis: P4996), but it allows patrolling edits in general.
  • NPPatrol is enabled on almost every WMF wiki (except for 4 wikipedias: P4996) . It ''essentially'' allows patrolling only new pages (the first edit of a page).

(The huge number of alternate/historical names for the [actions / activities / user-rights / user-groups / features] makes it all much more complicated!)

Turning it on, is desired for the benefit of:

  • edit-patrollers, who currently duplicate each others work, without knowing how much they're duplicating it. A single edit can be scrutinized by hundreds of editors, without any way to tell. (Eventual benefit, but no changes for now.)
  • the external tools which each have to maintain their own databases (huggle, snuggle, stiki, CVN, RTRC, etc) because RCPatrol isn't enabled in the databases on the wikis they cover.

Enabling RCPatrol

Enwiki turned it on-and-then-off-again in 2005, because:

  • A rapidly growing backlog, that some felt obliged to triage
  • A number of bugs that made it impractical at the time (e.g. self-patrol was possible for anyone)

Additionally, I believe / have-heard / vaguely-recall, that it was also because:

  • The red exclamation mark and/or the yellow highlight, annoyed some editors
  • Editors wanted the web of trust idea, because they didn't want to have to trust "any editor that I don't know" to patrol a revision on their watchlist. (See "Trusted Users idea" section below)
  • Editors had difficulty prioritizing edits to patrol, out of the firehose of incoming edits. (See T157715 for a possible solution, plus the ERI project as a whole)

Recommendation:

  • Turn on RC Patrol (the software) and just hide the RC Patrol status indicator ("!" in recent changes) (at the wikis that don't currently use it for that purpose). Thus, no one would be bothered who didn’t want to be. Then, over the medium-term, we can (collectively) slowly discuss future improvements, based on this newly available set of features and of now-interacting tools.

Old links for the 2005 RCPatrol enable/disablement at Enwiki:

Useful links, to other ongoing work, and historic discussions and proposals.

Related Phab tasks (incomplete)

Trusted Users idea

Main current features at Enwiki

Upcoming 2017 feature led by Cenarium

and the related:

Standard user-right and feature docs

Assorted other notes

Old notes from the 2010 Patrolled Revisions idea (not implemented because it would have been excessively difficult to technically have both this and Pending Changes protection enabled. The upcoming Passive Deferral feature is the updated similar idea.)

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 11 2016, 11:24 PM
jmatazzoni added a subscriber: Krinkle.

MediaWiki has a system for this already (RCPatrol), but some years back different communities decided to turn off this feature (for all but more advanced users). In English, my understanding is that some users objected to how the flag is displayed on RecentChanges (with a !).

"for all but more advanced users" may be combining two issues. My understanding is that there are two distinct concepts:

  1. Whether wgRCPatrol is enabled. It is disabled by default on Wikimedia wikis (I didn't realize that), but enabled on 74 wikis.
  2. Which users have the right to do 'patrol' actions. If a user has this right, they can do RecentChanges patrol, NewPages patrol (enabled almost everywhere), both, or neither, depending which is enabled on their wiki. Which users get 'patrol' also varies by wiki. (Users on English Wikipedia can also do PageTriage/PageCuration if they have 'patrol', which uses NPPatrol).

but enabled on 74 wikis.

91 wikis actually (72 individual *wiki, wikidata is a dblist of 2, and wikivoyage a dblist of 17).

Some interesting comments from @Mattflaschen-WMF on the notion of including Patrolled status in the ERI feed:

"We should bear in mind that the instant an edit has been made, it will only be patrolled if the user has autopatrol (the right to patrol their own edits).

Knowing an edit was auto-patrolled is somewhat relevant (since only at least somewhat trusted users should have autopatrol). But by definition most edits will not be patrolled here, so it could be somewhat confusing.

If we add actions, we could include the patrol action. "Previously made edit 123 was just patrolled".

Also, NewPage patrol (patrolling the first edit of a new page) is enabled almost everywhere, but not RC."

I don't understand the last two comments, about 1) actions and 2) NewPage patrol. Is the latter a separate patrol flag?

  1. Say at 8 PM I make an edit to Earth. I don't have autopatrol, so by definition it goes across the ERI feed as unpatrolled (if we have that field). We'll say it's revision ID 123. Later at 8:05 PM someone patrols revision ID 123. We could hypothetically then send a feed event "Revision ID 123, an edit to Earth, was just patrolled".
  1. There are two kinds of patrolling, but they both use the same rights, 'patrol' (patrol other people's edits) and 'autopatrol' (patrol your own edit):

2a. RC Patrol is disabled on most WMF wikis, but it allows patrolling edits in general.
2b. NP Patrol is enabled on almost every WMF wiki. It allows patrolling only new pages (the first edit of a page). It is used at https://en.wikipedia.org/wiki/Special:NewPages (core feature, not PageCuration) and https://en.wikipedia.org/wiki/Special:NewPagesFeed (PageCuration, which is only available on enwiki and test wikis).

Qgil added a subscriber: Qgil.Sep 15 2016, 8:05 AM

What is the priority of this task, and is it expected to be started/completed by the end of this quarter?

Quiddity triaged this task as High priority.Sep 16 2016, 8:01 PM

@Mattflaschen-WMF helpfully explained:

Say at 8 PM I make an edit to Earth. I don't have autopatrol, so by definition it goes across the ERI feed as unpatrolled (if we have that field). We'll say it's revision ID 123. Later at 8:05 PM someone patrols revision ID 123. We could hypothetically then send a feed event "Revision ID 123, an edit to Earth, was just patrolled".

Got it. Thanks. This is a crucial point, so let's take it one step further (assume we've enabled RC patrol):

Say at 8:06, I make a search on the RC page with a setting that filters out Patrolled edits. Is there a practical way for us to make it so that I'll filter out that 8PM edit to Earth? I.e., does the filter necessarily just read back the record of all the edits and return all the ones that weren't patrolled when they were made? (In which case the whole idea is kind of useless except for autopatrolled.) Or is there any way to work this--assuming we think it's valuable enough--so that the filter can check for an updated status of edits? If we had to reload the page when the Patrolled filter was used, that could be reasonable...

@Mattflaschen-WMF helpfully explained:

Say at 8 PM I make an edit to Earth. I don't have autopatrol, so by definition it goes across the ERI feed as unpatrolled (if we have that field). We'll say it's revision ID 123. Later at 8:05 PM someone patrols revision ID 123. We could hypothetically then send a feed event "Revision ID 123, an edit to Earth, was just patrolled".

Got it. Thanks. This is a crucial point, so let's take it one step further (assume we've enabled RC patrol):
Say at 8:06, I make a search on the RC page with a setting that filters out Patrolled edits. Is there a practical way for us to make it so that I'll filter out that 8PM edit to Earth?

Yes, this is already implemented (the new UI will be different, and will also need hideunpatrolled, though). https://www.mediawiki.org/wiki/Special:RecentChanges has "Hide patrolled edits", and this is how it works. (You have to be an admin to see it, so you could ask someone, e.g. Roan to show you.)

I'm contacting Polish Wikipedia now. They are not on the list.

Polish Wikipedia uses Flagged revisions. What would be the compatibility with RCPatrol?

Polish Wikipedia uses Flagged revisions. What would be the compatibility with RCPatrol?

They are orthogonal systems and should work separately without issue. In fact, FlaggedRevs even has special RCPatrol-integrations available so that it will synchronise its review system into the patrol system if enabled. It automatically marks-as-patrolled any edits that are reviewed through the FlaggedRevs system to avoid duplicate efforts.

There are various wikis that already have RCPatrol and flaggedrevs enabled. Compare https://github.com/wikimedia/operations-mediawiki-config/blob/master/dblists/flaggedrevs.dblist and https://noc.wikimedia.org/conf/InitialiseSettings.php.txt (search for RCPatrol).

Polish Wikipedia uses Flagged revisions. What would be the compatibility with RCPatrol?

They are orthogonal systems and should work separately without issue. In fact, FlaggedRevs even has special RCPatrol-integrations available so that it will synchronise its review system into the patrol system if enabled. It automatically marks-as-patrolled any edits that are reviewed through the FlaggedRevs system to avoid duplicate efforts.

Thanks! I didn't fould that information in the documentation.
That synchronisation will ease the deployment, because it will be invisible to the users.

There are various wikis that already have RCPatrol and flaggedrevs enabled. Compare https://github.com/wikimedia/operations-mediawiki-config/blob/master/dblists/flaggedrevs.dblist and https://noc.wikimedia.org/conf/InitialiseSettings.php.txt (search for RCPatrol).

I'll look at it to identify which wikis have FlaggedRevs but not RCPatrol too.

Quiddity closed this task as Resolved.Mar 3 2017, 8:00 PM
Quiddity updated the task description. (Show Details)

I've done all the reading I can, and discussed with various people. I've updated the task description with the conclusion and notes. I'm Resolving, but feel free to re-open/re-assign if more needs to be done.

jmatazzoni reopened this task as Open.Nov 22 2017, 9:05 PM

I'm reopening this just so no one gets the wrong idea that we've done anything about it outside of this analysis (for which, thanks Nick!). Feel free to take it off your boards if you please. I'm moving it to our Triage board, Near Term. I can dream!

Elitre added a subscriber: Elitre.Nov 23 2017, 11:58 AM

If this task is about the analysis, why not making a followup one for everything else? otherwise it looks like Nick still has work to do here, which I don't think is the case.

Quiddity removed Quiddity as the assignee of this task.Nov 23 2017, 7:35 PM
Quiddity added a subscriber: Quiddity.

Solved! :)