As we think about building new patrolling experiences for Wikipedia editors, it has become apparent that it would be useful to know if a patroller has already looked at an edit and deemed it acceptable. As we're aiming to surface edits needing patrolling, in general we want to avoid showing users known good edits.
Wikis can use the $wgUseRCPatrol configuration (Patrolled edits) to add per-edit patrolling capabilities, or use the FlaggedRevs extension. On wikis not using RCPatrol or FlaggedRevisions there is generally no easily accessible signal that a given edit has been reviewed already. It's not desirable to roll out FlaggedRevs to more wikis, but RCPatrol is a core MediaWiki feature which would be very easy and lightweight to turn on for more wikis.
There has been more than one discussion on at least English Wikipedia, through which editors have expressed that they do not want per-edit patrolling. We want to review these discussions and see if there are code or configuration changes we could make that would make rolling this feature out more acceptable, and assess prioritising those changes.
How RCPatrol works
- On Special:RecentChanges, Special:NewPages, and Special:NewFiles, users with the patrol user right see a red exclamation mark next to edits which have not been marked as patrolled.
- Users with the patrol user right can mark edits as patrolled.
- Users with the autopatrol user right have their edits marked as patrolled automatically.
- French Wikipedia automatically grants autopatrol to users who have made more than 500 edits and created their account 90+ days ago.
- By default, bots and sysops have the autopatrol user right, and sysops have the patrol user right.
- Wikis can configure patrol of individual edits, patrol of new pages, and patrol of new files, separately. English Wikipedia, for example, uses the new page patrol function.
- Edit patrol status is only tracked for 30 days.
RCPatrol is enabled on 32 Wikipedias - the biggest Wikipedias using it are French, Italian, Portuguese, Persian, and Dutch. It is also deployed to Wikidata, Wikifunctions, and Commons. It was deployed to English Wikipedia (and others?) in 2005, but a discussion at the time was overwhelmingly negative about the feature, and it was disabled a few days later.
Rationale/benefits
- Moderators save time by only needing to review edits which are likely to still require human review.
- When software invites newer editors to review edits, we can be more confident that their time will not be wasted reviewing known-good edits.
- New editors may find it motivational to learn that their edit has been reviewed by an experienced editor (T410882).
- Existing tools could use a central definition of 'patrolled' rather than inventing and storing their own data on which edits have already been reviewed.
Prior discussions
- Wikipedia talk:Checked edits brainstorming (2005)
- Mini-sondage du jour : affichage des modifications non-lues (2011)
- Enable RC patrolling (aka patrolling for edits) (2023)
Potential issues to address
- On English Wikipedia, some users highlighted that patrol and autopatrol rights have been granted in the context of pages, not edits, and it wouldn't be desirable to have all new page patrollers have all their edits autopatrolled without further review.
- We could split the patrol user right for new pages from new edits (and new files) - T308153
- General concerns that this feature does not add any benefits, because existing patrolling workflows already catch bad edits, and could lead to obscuring bad edits if they're erroneously marked as patrolled.
- One data point - Huggle, which a lot of patrolling on enwiki is done through, has a 'Good edit' button, which is analogous to patrolling an edit, except that it adds to a score for the user, and their edits are not displayed to users after so many 'Good edit' flags, not immediately from one.
- On English Wikipedia 39% of vandalism patrolling is done with the assistance of tools, many of which are already doing this kind of filtering (T348862)
- We could add optional configuration to hide all user facing elements of this system and only use it for any new patrolling tools we build. In this way all existing processes continue to work as they currently do, but we get the benefit of an existing patrol status system.
- Editors should double check each other's work - one user marking an edit as patrolled shouldn't hide it from other editors.
- Nothing is hidden by default, users can optionally filter out patrolled edits in RecentChanges. That said, we could imagine an optional config that requires X patrols before an edit is considered 'patrolled'.
- More broadly, perhaps patrolling shouldn't be a binary 'patrolled' / 'not patrolled' classification. We could be storing more granular data so tools and users can decide what level of patrolling they want to filter out. e.g. only edits patrolled by an admin?
- Exclamation point to flag unpatrolled changes is poorly designed.
- RCPatrol generates a new backlog, and editors will feel stressed that there are a large number of edits which have not been reviewed.
- We could investigate adding features to Automoderator to mark good edits as patrolled, not just to revert bad edits - T392825