Wikimedia Meta-Wiki

Community Wishlist Survey 2021/Admins and patrollers/Implement deferred changes

< Community Wishlist Survey 2021‎ | Admins and patrollers

Implement deferred changes

  • Problem: Aside from edits blocked by the edit filter, vandalism and other damaging edits (particularly those on BLPs) can still be viewed on pages for a short amount of time before they are reverted. According to a 2012 study by the Signpost, around 10% of damaging edits are seen by more than 100 readers, affecting the credibility of Wikipedia. The persistence of vandalism and BLP violations on low traffic biographies of living people is a lingering problem. Despite anti-vandalism bots and semi-automated tools, a substantial proportion of those damaging edits is not identified and reverted in a timely manner. (w:Wikipedia:Deferred changes).
  • Who would benefit: Readers, as they are less likely to view vandalized pages. Vandal patrollers, who will have more time to revert edits. Wikipedia's mission and reputation, with less BLP vandalism.
  • Proposed solution: Implement w:Wikipedia:Deferred changes, which basically means that edits, rather than just pages, can be sent in for review. Classification of suspicious edits can be done with edit filters, m:ORES and by bots (eg ClueBot NG's classification system). Since bots revert at a relatively high threshold to avoid false positives, this will give them more slack (as they can use lower limits just to flag it as deferred) and hopefully catch more vandalism. Similarly, looser edit filters can be used to flag for defer. This would open quite a few new doors for anti-vandalism work.
  • More comments: This project has been previously developed mainly by w:User:Cenarium, and has gained near unanimous support in a 2016 RfC on enwiki. Cenarium is now inactive, but it seems like they finished the bulk of the code needed to make this happen even in the unfinished commits, so this shouldn't be too much effort to pick up where they left off and complete.

Commits at w:Wikipedia:Deferred_changes/Implementation: however some of these commits are no longer necessary since an equivalent has been merged in since 2020, eg by Ostrzyciel's work on reverted edits, and our work on Echo notifications in gerrit:608884, so slightly less work needed to make this happen)

Discussion

Haven't had much time to edit Wikipedia recently. Thank you for reproposing. Darylgolden (talk) 08:23, 26 November 2020 (UTC)[reply]

  • @ProcrastinatingReader:, I can't recall if it was you I chatted about this with on en-wiki some time in 2020, but as then, I think this is unwise. Primarily because of the same reasons that pending changes has issues - the system doesn't handle stacked edits well at all. This could generate a major bulk-up in reviewable edits (even if far less than putting the pages on PC). A single deferred edit would stack up edits behind it, which is particularly problematic if some of them are good and others not. Reviewing these blocks is a massive pain, so they get avoided, so they get worse. I could only support this if there was a simultaneous fix to make handling of pending changes better and smoother (which was proposed 2 years ago, but didn't get the votes). Nosebagbear (talk) 15:52, 2 December 2020 (UTC)[reply]
    It could've been, I've kept an interest in this since around June. I can sympathise with your points. Improved edit conflict handling, like 'branches' of edits and 'merging' them (in a git-like manner) would also be an improvement, but I feel the crux of what you describe is mostly an enwiki culture issue. Often we don't want to press accept or decline ourselves in edge cases, since someone gets on one's case if a mistake was made, but if a bot does it for "staleness" that's all okay. I think we can work around these issues in a policy/culture way, we don't really have a shortage of editors able to accept. Mainly, we're just shifting the order from (in an ideal case) a Huggler reverting to a person approving [the edit]. If that fails, abusefilter editors can be 'conservative' on what filters are appropriate to send for review than others? ProcrastinatingReader (talk) 01:01, 11 December 2020 (UTC)[reply]
    @Nosebagbear: Also note this 'disadvantage' only applies for active deferring. Passive deferring will still allow the change to show up as normal, so people keep editing while it's added to the queue. If backlogs grow, we can adjust our config parameters or have a bot automatically remove 'stale' changes. ProcrastinatingReader (talk) 11:09, 11 December 2020 (UTC)[reply]
  • I can see benefits but there is a risk that anyone's queued edit could effectively lock the article until a suitably privileged reviewer deals with it. That problem might even be exploited as a denial of service vector. Certes (talk) 01:08, 11 December 2020 (UTC)[reply]
    "Passive deferring" is also possible with this change, rather than "active deferring", which simply queues the edit for review but still allows people to view the edit live in the meantime. And filter tweaks can be used to limit attack vectors. Also see Mz7's comment in the RfC close which addresses this concern. ProcrastinatingReader (talk) 01:16, 11 December 2020 (UTC)[reply]
  • As a few people have asked me this now, perhaps this information will be helpful: "Pending changes" allows admins to manually send in all edits to a particular page for review. This change ("Deferred changes") allows automated tools to "flag" an edit, and make it so that edit is put in for review (either before it shows, or let it show while still allowing it to be sent in for review). ProcrastinatingReader (talk) 11:06, 11 December 2020 (UTC)[reply]
  • Are you basically trying to reïnvent FlaggedRevision's stabilisation feature? --Base (talk) 18:51, 17 December 2020 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2021/Admins_and_patrollers/Implement_deferred_changes&oldid=20869406"