User:SM5POR/Proposals
Community Wishlist Survey 2022
editDisruptive edit notification watchdog
editSubmitted to the Notifications category of the 2022 survey on January 18, 2022.
Withdrawn and archived on January 21, 2022, due to a mistaken assumption about restore.
Existing MediaWiki tools relevant to this proposal:
In August 2020, the submitter of this proposal discovered that an obviously mistaken restore operation on a semi-important Wikidata item had apparently gone unnoticed for 15 months; see the report written at the time for a more detailed background. The effect of the restore had already been partially cancelled out by subsequent edits throughout those 15 months, and upon discovery that process was then completed by another editor whose edits had been lost in the restore.
Due to the submitter's lack of insight into the workings of the MediaWiki software or the procedures for filing issues of this kind, the report was never sent elsewhere, nor did the submitter find confirmation that the issue had somehow been independently resolved or even acknowledged by the MediaWiki developers.
As is emphasized in the earlier report, a restore operation might effectively destroy the object to which it is applied, returning it to the embryonic state it had upon creation. While the restore operation may itself be reverted, this is of little help if nobody is even notified about the restore in due time.
Rather than spending efforts on crafting a fix applicable to this particular and probably rare situation on the Wikidata platform only, this proposal aims at creating a generic watchdog feature to alert MediaWiki users (including admins and editors), using the Notification feature, about potentially disruptive edits, that could be configured to selectively cover any specific situation of concern, such as a restore operation by a novice user eliminating months or years of work on a little-known object unlikely to be on anyone's watchlist.
A cross-wiki solution implemented in MediaWiki could also complement or replace some of the Special pages already implemented, or eliminate the (maybe hypothetical) desire for users to obtain part of the information in less efficient ways, such as having robots constantly monitor the Special:RecentChanges list or patrol the wikis in search for undesirable edits.
The watchlist feature already exists, and serves a similar purpose for specific pages or other objects. Using it to watch every object in the same wiki for specific kinds of edits seems however unfeasible, wherefore a watchdog could instead be designed and tailored to serve the purpose described in this proposal.
Also, given the multitude of criteria that may have to be combined in order to filter out only those edits that the user is actually looking for may require a configuration page that is a bit more complex than the current Special:Preferences page. Therefore this proposal suggests placing these settings in a new Special:Watchdog page rather than adding a limited number of check-boxes (such as "Watch every Wikidata item, property and lexeme for non-logged-in or new user restores affecting edits made more than 1 month ago") to the former.
To make the project fit within the time constraints of the 2022 round of proposals, the emphasis here should be on making the core watchdog feature generic enough to allow gradually extending it with new options as the needs arise and time permits. Essential core functionality identified so far:
- Watchdog feature configurable on a per-wiki basis
- Feature available to all users (subject to its configuration)
- Selectively applicable by users to detect:
- Certain types of changes (object creation, deletion, plain edits, reverts, restores)
- Changes of objects matching certain criteria (of a particular type or belonging to a particular category or namespace, as defined by the wiki configuration)
Potential future options (not themselves part of this proposal, but listed now to allow future extensions to be implemented with minimal changes to the core watchdog feature) include:
- Filtering alerts on editor status (such as whether logged-in, auto-confirmed, admin, bot etc)
- Filtering alerts on environmental criteria (such as day of week, time of day, or software version)
- Triggering alerts on quantitative criteria (such as edits made to objects created a long time ago or not changed at all for a long time, multiple edits made in a short period of time, edits affecting the joint work of many editors)
- Expiration of per-user watchdog settings
- Suppressing large quantities of alerts which the user is unable to handle
- Not issuing alerts to users not currently logged in
- Directing alerts to other receivers than users, such as log files or counters
- Ultimate integration with the watchlist feature, to apply the watchdog only to selected individual pages or other objects