Currently, wikis have the choice of implementing either new page patrol that allows patrolling new pages only, or full recent changes patrol. The problem of full RC patrol is that on big wikis, the absolutely massive number of edits to patrol makes the task almost impossible (the patrol of new articles is already heavily backlogged on enwiki). There is no way to find out (besides edit summaries and size changes) which edits need patrolling the most.
With ORES, we have an additional indication that an edit is in particular need of patrol, but on wikis not using RC patrol, we still can't patrol the edits.
Change tags allow to flag an edit in a particular way, and can help prioritize patrol, but we have the same problem as above.
With deferred changes, we have an effective way to patrol those edits, but for various reasons the backlog must be kept low. So it is good to prioritize patrol of edits identified as highly suspicious by AIs, but not for those edits identified as somewhat suspicious.
Therefore, we need a way to:
- on wikis using full RC patrol UI, highlight some edits as being especially in need of patrol, end users would there have three filtering options: none, unpatrolled, needs patrol
- on wikis not using full RC patrol UI, make it possible to patrol edits considered especially in need of patrol, end users would there have two filtering options: none, needs patrol.
It should be possible to mark an edit as being in need of patrol either via: extensions: ORES, as it does already but this could be integrated in this framework, AbuseFilter, and via the API for bots. In addition FlaggedRevs should mark the edit as needing patrol when it defers an edit.
So we would need three states of patrol: -1 for 'needs patrol', 0 for 'unpatrolled' and +1 for 'patrolled'. Unfortunately rc_patrolled is unsigned in the recentchange table, but if we can fix this, the implementation should be relatively straightforward.