Page MenuHomePhabricator

Request for Locking Pages During Patrol to Prevent Duplicate Efforts
Open, Needs TriagePublicFeature

Description

Feature summary (what you would like to be able to do and where):
I would like the edit patrol feature to include a mechanism that "locks" a page when someone starts patrolling it, preventing others from reviewing the same page simultaneously. This would apply to the edit patrol process across Wikipedia.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
When patrolling edits, users may start reviewing a page and spend time investigating the changes. However, by the time they finish, another user may have already reverted the edit or taken action on it. This results in wasted time and effort for the second user, who had no indication that the page was already being patrolled by someone else. The underlying problem is the lack of a system to notify users that a page is already under review, leading to duplication of efforts.

Benefits (why should this be implemented?):
Implementing this feature would streamline the patrolling process by preventing multiple users from working on the same page at the same time. This would save time, reduce frustration, and improve the efficiency of edit patrols.

Event Timeline

JTannerWMF moved this task from Needs Triage to Garage on the Wikipedia-Android-App-Backlog board.
JTannerWMF added subscribers: Samwalton9-WMF, JTannerWMF.

We want the Moderator Tools team to think about this first

I can see the benefit of this. We briefly considered something like this for Automoderator - such as adding a flag to the recentchanges table to highlight that Automoderator hasn't reviewed the edit yet, so that patrolling tools like Huggle could avoid displaying it, which may be a waste of patroller time if Automoderator then reverted it. Ultimately Automoderator's time to revert is on the order of seconds, so the potential impact seemed pretty low.

I think this would probably be best at the patrolling-feature level, not the page level, i.e. the Android patrolling feature could avoid displaying the same edit to multiple users in a short period of time. It would be hard to collate all the different ways an edit might be reviewed (Anti-vandalism bots, external tools like Huggle, Recent Changes, Android patrolling ...) into one "someone's looking at this" data source.

The only downside I see is that it may be hard to tell the difference between someone who opened an edit in the patrolling feature and put their phone down and someone who opened the edit and then went to search the internet to verify the change. If we can't tell that someone is actually actively reviewing an edit we risk letting bad edits sit around not actually being reviewed by anyone. Perhaps prioritising the edits you show to a user in the patrolling tool based on how many other users they've recently been shown to could be one approach to minimise this situation from occurring.