Page MenuHomePhabricator

Refuse to execute null edits for +bot-flagged users
Open, Needs TriagePublic


As I proposed, to combat the 60% (!) of all edits that are bot-made null edits since December.

Not fully thought-through.

Event Timeline

Have you looked at why these bots are doing that?

Should probably only apply if the user is trying to make an edit marked as a bot, i.e. they're actually using their bot right rather than simply holding the right to do so

I don't know if this task is about index.php?action=edit, api.php?action=edit, api.php?action=purge or some other entry point.

I agree with @Peachey88: we should examine the underlying motivations here. If many users are feeling the need to manually purge pages, the problem isn't the purging, per se, the problem is that various caches aren't getting cleared quickly enough for users. This might point to the job queue, it might point elsewhere.

We partly have a user documentation and architecture issue here. If we have action=purge and &forcelinkupdate and &forcerecursivelinkupdate as part of api.php, are users ever told why this action exists and when they should and should not be using the purge action? Looking at it doesn't seem so.

This bug is related to T56902: Deprecate and remove the purge action from MediaWiki. In my opinion, the purge action should never be needed. However, in my experience, categorylinks and other links can sometimes not update for days and eventually you get sick of waiting around.

If you stop users in the "bot" user group from doing null edits, I imagine you'll just see a rise in the number of users not in the "bot" user group doing them. We could consider tightening rate limits if there are performance issues, but someone from Wikimedia operations would have to speak to whether that's the case.

One reason I see for the need of a null edit is that the articles from the categories take forever to be updated when the categories are added automatically through templates that use Wikidata to update. It can be specially annoying when this categories are maintenance categories and you have to wait until there is a legitimate edition to the modified pages to update the category links. At the end it's common to end up making null edits or &forcelinkupdate to update the category and know which pages are really still requiring maintenance.

As a side note I want to make clear that this is not affecting the contents of the page, this ones are updated quite fast (even the categories of the footer are correct), the problem is that even if the pages are updated they still appear in the categories (even if the categories of the footer say that they should not).

Once was resolved, how much of an issue is this actually? Given that null edits are useful hacks and we do have bots that intentionally make them, we should identify outliers and work to fix bots that are malfunctioning.

TTO renamed this task from Refuse to execute null edits for +bog-flagged users to Refuse to execute null edits for +bot-flagged users.Jul 31 2016, 11:44 PM