Change 329651 had a related patch set uploaded (by Cen.temp):
Set base revision id for EditPage

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

Change 330587 had a related patch set uploaded (by Cenarium):
Notify users of multiple-revisions undos

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

Change 608884 had a related patch set uploaded (by Ostrzyciel; owner: ProcrastinatingReader):
[mediawiki/extensions/Echo@master] Notify users of multi-revision reverts; EditResult-related cleanup

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

Change 608884 had a related patch set uploaded (by Ostrzyciel; owner: ProcrastinatingReader):
[mediawiki/extensions/Echo@master] Notify users of multi-revision reverts; EditResult-related cleanup

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

I noticed some cases where I don't think the manual edit tag should be applied, and in particular where triggering a notification will probably annoy users. I wrote the details in T256001#6489764, although I'm not sure which bug is the most appropriate to discuss this.

In T154637#6489777, @Orlodrim wrote:

I noticed some cases where I don't think the manual edit tag should be applied, and in particular where triggering a notification will probably annoy users. I wrote the details in T256001#6489764, although I'm not sure which bug is the most appropriate to discuss this.

I guess here :) This is a valid point, I did not realize Wikipedia utilized bots so heavily for tasks like these. Do you have any ideas on how could this be fixed?

I can think of for example disabling revert notifications for reverts made with the bot flag, but I'm not sure if all bots you've mentioned in T256001#6489764 actually use the bot flag. I am also unsure about whether there are "legitimate" uses for reverting with the bot flag on Wikipedia. Could you tell me whether this would work, based on your experience? I think we can assume that any solution is "good enough" as long as it works for Wikipedias, as they are the biggest users of Echo.

I can think of for example disabling revert notifications for reverts made with the bot

Maybe we shouldn't apply the manual revert tag at all for bot edits, then?

In T154637#6490416, @kostajh wrote:

Maybe we shouldn't apply the manual revert tag at all for bot edits, then?

Not sure. The bot flag's primary goal seems to me to be to hide the bot activity in the recent changes feed from most editors/moderators in order to reduce clutter. A good hint of that is the fact that the bot flag is not persisted permanently (e.g. in the revision table), but rather in the recentchanges table only, which would correlate with our concerns about notifications here.

I would be for just disabling the notifications for bots.

I agree that excluding bots would be a sane default.

Whether this should be done by looking at the bot flag of individual edits or by checking the status of the user, I am not sure. Some pros and cons:

On the French Wikipedia, almost all bots tag all their edits with the bot flag except the anti-vandalism bot (Salebot). Salebot intentionnally does not use the bot flag for reverts to make them visible in recent changes.
Since Salebot works by doing manual reverts, disabling manual reverts notifications based on the bot flag for specific edits would work exactly as it should on the French Wikipedia (Salebot would trigger it and not the other bots).

On the other hand, using the bot status would be more consistent with other situations where bots are handled in a special ways. I know at least the following:

1. Bots do not trigger a new message notification when they mark edits on user talk as minor (independently of whether they mark them as bot edits).
2. Bots do not trigger notifications when they mention a user in the edit summary (T189040)
3. Bots do trigger notifications when they mention a user in a signed message, but there is a blacklist to exclude them when needed (MediaWiki:Echo-blacklist).

Making the notification depend on the status would at least be consistent with 1 and 2, whereas using the bot flag for the edit would introduce yet another special way of treating bots.

Independently of that, in the second case that I mentioned (lists of things to do), a bot is involved but the notification is not triggered by the bot. It is triggered by the user removing the last item in the list.

In that case, I just thought of a simple workaround for the bot owner: make the bot write the "last update" date on the list. Alternatively, there could be a magic word to disable the notification on specific pages, but this sounds a bit hacky. So there isn't necessarily something to do about it on MediaWiki side, but it would be good to communicate about the change. I can only update my own bot.

Hmm.

Making the notification depend on the status would at least be consistent with 1 and 2, whereas using the bot flag for the edit would introduce yet another special way of treating bots.

I would be for looking at the flag for the particular edit, that makes the most sense for me. It does make Echo a bit less consistent, but that's justified here, IMO. @kostajh, what do you think?

Also thank you @Orlodrim for the analysis! :)

There are cases when bot reverts should be notified. The most obvious one to me is ClueBot, https://en.wikipedia.org/wiki/Special:Contributions/ClueBot_NG. Edits are marked as minor, not sure if they're marked with bot too. Second, sometimes bots edit articles and the contributors don't want that bot edit. Many bots will edit again if the bot is reverted (they're not that smart), so notifying editors that a bot manually reverted them would seem a good idea. Such bots (at least on the English Wikipedia) will be flagged as bots, and typically mark their edits with bot: true as well, so using the fact of whether or not the particular edit by a flagged bot was also marked as a bot edit won't work.

Seems a complicated issue. Further, a lot of bot operators are inactive, so expecting them to change their bots would not practically happen. I think one idea may be a way to mark a particular edit with something like should_notify: true (for bots only), creating an opt-in system (by default, bot edits would not notify). I don't know how practical that is, in terms of developer effort, however.

In T154637#6496030, @Proc wrote:

I think one idea may be a way to mark a particular edit with something like should_notify: true (for bots only), creating an opt-in system (by default, bot edits would not notify). I don't know how practical that is, in terms of developer effort, however.

If we could make this work, it'd be awesome and could potentially help solve other issues with bots and Echo. I will look into it in a few days. :)

Right, so I've thought about it a bit and something like a should_notify parameter would be rather hard to implement. We would have to modify the appropriate API module and then somehow push that information through the really ugly MediaWiki editing pipeline (EditPage and PageUpdater especially) for the extension to even have a chance of noticing the parameter. That seems like a lot of work. Alternatively I can think of a few very, very ugly hacks that would not pass code review.

I don't think it's worth it, bot owners can work around that issue.

There are cases when bot reverts should be notified. The most obvious one to me is ClueBot, https://en.wikipedia.org/wiki/Special:Contributions/ClueBot_NG.

The bot appears to notify users on its own, see this page for an example: https://en.wikipedia.org/w/index.php?title=User_talk:80.94.196.114&oldid=981306957 I guess this makes it a non-issue :)

Second, sometimes bots edit articles and the contributors don't want that bot edit. Many bots will edit again if the bot is reverted (they're not that smart), so notifying editors that a bot manually reverted them would seem a good idea.

Yeah, that's possible, but one could argue that it's the bot's (or the bot operator's) fault here.

Overall, after considering all the pros and cons, I am for disabling manual revert notifications for edits made with the bot flag. That should be simple and effective in most cases.

In T154637#6509215, @Ostrzyciel wrote:

The bot appears to notify users on its own, see this page for an example: https://en.wikipedia.org/w/index.php?title=User_talk:80.94.196.114&oldid=981306957 I guess this makes it a non-issue :)

Also, ClueBot NG reverts have the "rollback" tag, which I guess implies that it uses the rollback API instead of doing "manual" reverts.

Overall, after considering all the pros and cons, I am for disabling manual revert notifications for edits made with the bot flag. That should be simple and effective in most cases.

+1. If a bot intentionally does a revert, it can already do a proper one and not rely on MediaWiki to detect it as a manual revert. In other cases, I think having a dedicated parameter would add complexity to the API with little benefit. For a bot owner, ignoring the parameter would have no apparent consequences, so I guess most of them would just never set it.

I found of different situation not involving bots where it would be good not mark the edit as reverted, or at least not send a notification:

• Edit 1: BadUser vandalises an article
• Edit 2: BadUser vandalises the same article again
• Edit 3: GoodUser reverts edit 2 only
• Edit 4: GoodAndMoreCarefulUser also reverts edit 1

End result: Edit 4 is marked as a manual revert, while edits 1, 2 and 3 are marked as reverted. It is good to notify BadUser about that, but GoodUser will be confused if they get a notification that their edit was reverted by GoodAndMoreCarefulUser.

Toy example: https://fr.wikipedia.org/w/index.php?title=Utilisateur:Orlodrim/Manual_revert&action=history
Real example: https://fr.wikipedia.org/w/index.php?title=Jacques_Cartier&offset=20200917165917|174798553&action=history

In T154637#6510822, @Orlodrim wrote:

End result: Edit 4 is marked as a manual revert, while edits 1, 2 and 3 are marked as reverted. It is good to notify BadUser about that, but GoodUser will be confused if they get a notification that their edit was reverted by GoodAndMoreCarefulUser.

Does that happen often? We deliberately designed the manual revert/reverted system to state "yeah, this was technically reverted", without judging who's right or whose creative input was really removed from the page (that would require computationally expensive methods like diffing). I would also consider the current behaviour kind of half-bad, as the GoodUser is technically reverted here, because they made an error in not reverting the entirety of BadUser's input. It may be worth notifying them about this slight mistake. :)

Anyway, I don't see any obvious way to solve this and whatever we do may cause more problems with other complex revert cases.

But again, thank you a lot for noticing and reporting this!

In T154637#6511351, @Ostrzyciel wrote:

Does that happen often?

I listed them on https://fr.wikipedia.org/wiki/Utilisateur:Orlodrim/List_of_double_reverts for frwiki. This happens about 3 times a day on frwiki, which represents 1.1% of manual reverts (without bots).

Anyway, I don't see any obvious way to solve this and whatever we do may cause more problems with other complex revert cases.

Up to you. I think this specific case case could be resolved without text diffing with the following algorithm: among the revisions newly marked as "manually reverted" (excluding those that already have the tag), in case several ones have the same sha1, only notify the user who did the oldest one.

In T154637#6513557, @Orlodrim wrote:

Up to you. I think this specific case case could be resolved without text diffing with the following algorithm: among the revisions newly marked as "manually reverted" (excluding those that already have the tag), in case several ones have the same sha1, only notify the user who did the oldest one.

Huh, that's actually pretty smart, haven't thought of that. I think I'll have a go at implementing it, after some experimentation with pencil and paper. :)