@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.

In T11790#9780400, @Xaosflux wrote:

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

As I was reading through the comments I was going to say the same - I don't think we should implement this change for just one or two of the filters, they should all work consistently: Changes by you/others, Bot/human, Minor/non-minor, registration status, the ORES filters, and (I assume) tags when 'Exclude selected' is chosen. Presumably that makes it a bit more complicated to implement, but clarifies the behaviour greatly for users.

From a UX perspective, I think if this is implemented there should be some indication of whether the change you are seeing is or isn't the most recent revision to the page. A symbol placed at the start of a line showing the most recent revision to the page is what strikes me as the likely simplest.

In T11790#10662066, @Thryduulf wrote:

From a UX perspective, I think if this is implemented there should be some indication of whether the change you are seeing is or isn't the most recent revision to the page. A symbol placed at the start of a line showing the most recent revision to the page is what strikes me as the likely simplest.

This is a good idea, and along with the 'Reverted' tag which is now displayed for edits which have been undone, may resolve the issue pointed out above where an edit is reverted by a bot. There would be two indications on the reverted edit that something has happened since - this symbol, and the Reverted tag. I think that would substantially reduce the chance for confusion.

I think my idea here probably requires the user-setting for "Expand watchlist to show all changes" -- But just in case it inspires anything, or is useful to someone:
One tangential idea that I've used for years, is to change the opacity for certain things that I don't want to be distracted by, but also don't want to overlook entirely.

I do this by tweaking my custom CSS to add code like this:

/* Opacity for revert/ed-edits in history pages */
.mw-tag-mw-undo,
.mw-tag-mw-rollback,
.mw-tag-mw-reverted {opacity: 0.2;}

Which creates this before/after: