This problem is becoming disruptive on enwiki. It is precipitating a lot of mutual frustration between some bot operators performing maintenance tasks and vandal-fighters who don't want to miss potentially problematic edits. I see the last comment here was in September. Any prospect of a fix for this?

Agree this should be of top priority. Even more important in languages with a higher percentage of bot edits.

James

In the 2016 Community Wishlist Survey, a proposal for fixing this wound up at #47 (tied for #45) out of 265 proposals.

This bug also has the reputation as the or a genesis of troubles vandal hunters and others have with prolific bots, with troubles related to one of them rising to ArbCom.

Is there anything in particular blocking this from getting a fix?

The fact that (with the exception of Ilmari_Karonen farther up) nobody has proposed a patch to fix the issue, and Ilmari_Karonen's patch has the issue Quiddity mentioned. Someone with dev skills needs to write another code patch.

Hi @Opabinia_regalis and @Stevietheman.

In T11790#1799601, @Quiddity wrote:

(IIUC) What is actually wanted, is a preference that gives:

• Bot edits are hidden, and the previous edit to that page is shown instead, If and Only If, the bot edit was not a revert.
  • If the bot edit was a revert, then both edits should be hidden, and the edit prior to the reverted-edit, should be shown.

Do you agree with @Quiddity here?

The people interested in doing code development work for MediaWiki are often different from people who regularly check their wiki watchlists. This task as written is very difficult to resolve because it's unclear what the ideal/desired behavior is. Before anyone can fix this task, we need to nail down exactly what's being requested.

@MZMcBride : Point #1 is right. Point #2 would need a bit more discussion, especially about whether "revert" means "any revert" or just "rollback".

Right now, on enwiki aside from a few adminbots (none of which uses rollback if memory serves) only the antivandal bot and two additional bots (Filedelinkerbot by @Krd in order to self-revert and RscprinterBot by @Rcsprinter123 to revert test edits) have access to rollback.

I presume that presently, hiding rollbacks and rolled back edits in the watchlist for people who have set "hide bots" in their watchlist preferences may be unproblematic. Can't say of future bots or other wikis.

I wouldn't distinguish any revert from any bot. Whatever a bot reverts should be taken as bot edits to hide. After all, I believe the user that is hiding bot edits is seeking to see the latest non-bot/non-bot-reverted edit that occurred since they last visited the page.

If a particular user doesn't trust what a bot does when it reverts, they need to show bots to examine these things. There should be no middle ground until we have "hide trusted users/bots". :)

If there is some important aspect I'm missing, please anyone bring it up for me to chew on.

I don't think that all reverts by a bot by default imply that the reverted edit can be hidden. Since rollback is usually applied to vandalism and vandal edits are the problem case to hide here, I'd limit the "hide reverted edit" function to rollback so that different reverts can be treated differently if need be.

In T11790#2923791, @JEumerus wrote:

I don't think that all reverts by a bot by default imply that the reverted edit can be hidden. Since rollback is usually applied to vandalism and vandal edits are the problem case to hide here, I'd limit the "hide reverted edit" function to rollback so that different reverts can be treated differently if need be.

Note that the original edit reverted is being marked as bot already, so it currently doesn't appear even on recent changes. Of course, this only happens when the bot does action=rollback as provided by MediaWiki. The original (vandal) edit won't be marked as bot if the bot just performs a normal edit like an undo or editing a previous version of the page.

OK, I'm trying to understand. At this point, I don't understand why a rollback would be different from an undo of the directly preceding edit(s), for our purposes here.

If @JEumerus, @Ciencia_Al_Poder or anyone can describe a scenario for treating an undo of the directly preceding edits(s) differently from a rollback, that would help me see that.

@Stevietheman I think one major difference is that only admins can revert, but anyone can undo. So reverts are more likely to be trustworthy, in a way similar to bot edits, while undos are essentially regular edits, which need more scrutiny.

@Stevietheman: This task was originally fairly simple: there's an existing option to hide bot edits, which behaves as "show the most recent edit for each page, but remove the ones that are marked as bot". People wanted it to behave as "show the most recent non-bot edit for each page" instead.

At some point the task got a bit confused by people who wanted to take it one step further: "show the most recent non-bot, non-reverted-by-a-bot edit for each page". Adding that "non-reverted-by-a-bot" bit in there makes it much harder to accomplish. Further complicating the issue is the fact that the rollback feature includes an ability for eligible editors to retroactively mark the reverted edit as 'bot', but this ability is not available to other methods of reverting an edit.

Possibly the solution to the issue raised in T11790#1799601 is that bots doing reverting should either use rollback and the mark-as-bot feature or should not mark their own edit as 'bot'.

So in other words, a two pronged fix: Have the watchlist display the latest non-bot edit and prod the operators of bots who roll back unconstructive edits to have the bots mark the rolled back edit(s) as bot edit(s), so that these edits are hidden as well.

This seems like it would meet the criteria to define this task as "fixed".

@daniel, If an approved bot does a rollback or an undo of directly preceding edits, I assume it's performing an approved task and the edits reverted (either way) will therefore not be of interest to the watchlister. If this assumption is not true, I would like to read of a scenario that makes me go "hmmm, wait".

@Anomie, the "one step further" scenario is where I thought we were at, at this point (assuming the watched edit being shown hasn't already been cleared/visited by the user). I understand the solution of bots only using rollback and mark-as-bot. I don't understand "or should not mark their own edit as bot" -- after all, it's a bot edit.

On edit: I need to rephrase my answer to Anomie in my first sentence where I said "(assuming the watched edit being shown hasn't already been cleared/visited by the user)". I mean that it wouldn't be bolded if already visited, but the latest non-bot or non-bot-reverted edit would still be shown in the proper chronological sequence on the watchlist page. (OK, I'm going cross-eyed now)

@Stevietheman Oh, are we talking about bot edits only? If a *bot* does it, I don't see a difference between a revert and an undo. The actions are mostly equivalent, the difference is in who can perform them.

@JEumerus - that sounds right. I just wonder if there ''are'' any bots using undo instead of rollback for directly preceding edits. If not, this two-pronged fix seems like it will be enough to drive a complete solution.

@daniel, yes.

Now, I guess we have a different discussion with regards to 'Hide my edits' and 'Hide minor edits', the former being a non-problem in my view, as if one has made an edit to a page, they have cleared/visited it, so there's no point in seeing a recent edit behind it. I think. :)

@Anomie, I edited my response to you above for (hopefully) clarity.

Slow to respond, sorry - but yes, @MZMcBride, that description sounds accurate, with point 1 (which leads to missed vandalism) a higher priority than point 2 (which leads only to a wasted click).

I don't know of any real examples of bots using mechanisms other than rollback to revert, so the two-stage solution to the problem that relies on bot reverts using rollback with the markbot parameter sounds like the best approach.

Worrying about other "watchlist clutter" issues like hiding one's own edits, hiding minor edits, etc. seems to be scope creep. The bot issue is an issue specifically because of the high volume of bot edits.

I analysed the existing behaviour of the watchlist (with the enhanced watchlist turned off). This was what I found:

1. If the most recent edit to page X is a bot edit, and you elect to hide bot edits, then no edits for page X are shown on the watchlist at all. (That's what this task is about.)
2. If logged actions, like protection or importation, have been performed on page Y at any time during the user's chosen timespan, all such actions are shown on the watchlist, regardless of when they occurred or whether any edits have occurred in the meantime. (Yes, even on the non-enhanced watchlist.)
3. If certain logged actions have been performed on page Z since it was last edited, then no edits for page Z are shown on the watchlist - only log entries are displayed.

From looking at the code, it's hard to tell if these three behaviours are by coincidence or by design.

Unfortunately, these three behaviours are heavily intertwined, and it's difficult to fix point 1 without changing the behaviour of point 3 as well. Here's how the changed behaviour could look:

1. If the most recent edit to page X is a bot edit, and you elect to hide bot edits, then the most recent non-bot edit for page X within the last 30 days is shown.
2. A If logged actions have been performed on page Y since it was last edited, then only the most recent log entry is displayed.
3. A If, however, the logged actions were performed on page Y before the last edit, then only the most recent edit is displayed.

Or we could make less of a change to the non-enhanced watchlist's behaviour:

2. B All logged actions performed on page Y during the user's chosen timespan are displayed (as per current behaviour).
3. B The most recent edit to a page (according to the user's filter settings) is always shown, regardless of what (if any) logged actions have been performed.

I realise that there are other permutations that might be desirable - for example, showing both the most recent log entry and the most recent edit - but I think that would be prohibitively difficult to implement.

Which would be better? A or B?

Developers can play with an experimental patch at https://gerrit.wikimedia.org/r/332119

I am happy with either.

I'd probably prefer B. I don't think logged actions and edits should bury each other. Other people may disagree.

Thanks @TTO! For reference, I've just posted a note about this on the currently active enwiki arbitration case that relates to this issue (which is what prompted me to pay attention to this request in the first place).

Personally, I have a smallish watchlist and use the enhanced version, so am not the best person to ask about this. I'd prefer option B, but obviously I already established that I prefer more entries.

I'd go with B. I don't see any hard reasons for tinkering with the display of log entries in this context.

Change 332119 had a related patch set uploaded (by TTO):
Make filters skip over bot/minor edits in the old-style watchlist

https://gerrit.wikimedia.org/r/332119

For AWB

https://en.wikipedia.org/wiki/User:Evad37/Watchlist-hideAWB.js

I have now adjusted my watch list preferences such that bot edits do not hide none bot edits that occur before them. Was a little complicated to set up but works.

We are considering this for Growth team maintenance work.

There are a number of improvements I would love to see to watchlists. Some of them are simple changes to layout. Was planning on putting together a proposal for the community tech team.

I have now adjusted my watch list preferences such that bot edits do not hide none bot edits that occur before them. Was a little complicated to set up but works.

@Doc_James could you please share with us the steps you took to configure your watchlist in this way? Also, are you using the old style watchlist or the new one?

Will do so in a few days when I am home

Okay so I have turned on:

1. Under preferences -> recent changes -> Group changes by page in recent changes and watchlist

2. Under preferences -> watchlist -> expand watchlist to show all changes, not just the most recent, hide bot edits from the watchlist

3. I have unselected under preferences -> watchlist -> hide the improved version of the watchlist

Appears to work. But would need to test it on a new account to verify that I am not missing anything. Can send you screen shots if you wish.

Change 1012119 had a related patch set uploaded (by Sohom Datta; author: Sohom Datta):

[mediawiki/core@master] [WIP] Make sure the last non-bot/non-minor revision is picked for watchlists when a user disables bots/minor edits

https://gerrit.wikimedia.org/r/1012119

This is a general condition about filters, not specific to only the 'bot' or 'minor' filter

e.g. If you pick 'hide unregistered users' it will hide the entry if the latest user was unregistered, it won't then start showing the last non-unregistered user - same as for the other filter types

This means for example that people can vandalize articles as much as they want and then simply request e.g. Citation bot to fix a few minor issues in the article to hide their changes from people's watchlists. It's certainly not what many if not most users trying to hide bot edits from the watchlist through checking "Human (not bot)" think will happen. So this is really very important, can't believe it's apparently open since 2007 and was in the Wishlist in 2016 – since there is a patch what is the problem with it? Even disabling the bot edits filter until there is a better solution would be better than doing nothing.
Probably the item in the Watchlist should be sorted chronologically according to the last human edit so it would be further down and the edit summary shown there the last human edit (when one clicks on the diff button it would show the last human edit, not the latest edit which is some bot edit). A Watchlist feature to see a diff of all changes of an article with one click as well as a way to exclude edits by e.g. Citation bot, InternetArchiveBot and OAbot from diffs (esp. such large diffs) are also needed.

Edit: the same issue also exists in the Global Watchlist.