@valhallasw Well, only those in acl*Batch-Editors can use the bulk edit feature, which is a vetoed group of users. I wouldn't rate them as "untrusted".

Testing bulk action

Ah, I had not realized bulk edits were a restricted group. Unfortunately, it doesn't help much...

The above two comments are represented in the feed as follows:

"PHID-STRY-7g5tah34m77nt5u64kkk": {
  "class": "PhabricatorApplicationTransactionFeedStory",
  "epoch": 1569759365,
  "authorPHID": "PHID-USER-m5jpn3aks3txixuwk5pn",
  "chronologicalKey": "6742065136132927619",
  "data": {
    "objectPHID": "PHID-TASK-4obcikrq4tjuzhziuto7",
    "transactionPHIDs": {
      "PHID-XACT-TASK-hq5isqis26iq3yy": "PHID-XACT-TASK-hq5isqis26iq3yy"
    }
  }
},

"PHID-STRY-l4rxvnejtatmd46dzky4": {
  "class": "PhabricatorApplicationTransactionFeedStory",
  "epoch": 1569762099,
  "authorPHID": "PHID-USER-muirnivxp5hzppn2a3z7",
  "chronologicalKey": "6742076878012827197",
  "data": {
    "objectPHID": "PHID-TASK-4obcikrq4tjuzhziuto7",
    "transactionPHIDs": {
      "PHID-XACT-TASK-gemsavgtqwnywiw": "PHID-XACT-TASK-gemsavgtqwnywiw"
    }
  }
},

Unfortunately I don't see a way to determine whether an event (STRY) was caused by a bulk edit or not through the API.

It _is_ exposed in the web interface (hover over the time of change element). So it is stored somewhere internally. Scraping it may be possible, in the same way we used to scrape to get the anchor urls -- but those are (as one may have expected) broken as the html as changed in the meanwhile.

So.. if anyone feels lucky and wants to try to a) get the information added to the api or b) to web-scrape the task page and maintain that scraping in the future, I'm willing to accept a patch that hides all batch changes.

But before we do that, I'd like to make sure there actually is consensus to do so, esp. from the ComTech team and @Aklapper. The extra step of having hidden changes go through a smaller set of users does make sure that the hidden process is only used for non-controversial changes.

To me this is a clear wontfix/declined. We don't want users not to get notified about actions that they expect to get notifications about, according to their settings.

For large bulk actions, feel free to file a ticket if you think they should be silent for some reason. (To me that feels out of scope for both @CommunityTechBot and @Maintenance_bot.)

when that might cause a ping flood for the user (esp if using IRCcloud, which doesn't yet allow to mute notifs from an IRC user).

Then the user should fix whatever application they use for IRC, to not notify them. Why should wikibugs work around IRCcloud problems?

In T231733#5532398, @Aklapper wrote:

To me this is a clear wontfix/declined. We don't want users not to get notified about actions that they expect to get notifications about, according to their settings.

Which settings?

https://www.mediawiki.org/wiki/Phabricator/Help#Receiving_updates_and_notifications (which is about mail and not IRC, but I don't see why IRC is supposed to get special-cased here)

IRC is a bit different as it's a broadcast notification in addition to the regular email notifications. Because it's a broadcast, it's also not possible to configure it per-user (other than filtering in your IRC client).

If I understand correctly @CommunityTechBot and @Maintenance_bot do not send any notifications at all? So then what (I think) Urbanecm is proposing is the following

Yes.

16:36 -!- wikibugs [~wikibugs2@wikimedia/bot/pywikibugs] has quit [Excess Flood]

does this action show up on IRC again?

It does and should that's fine and expected, IMO :)

Yes, it was a test after wikibugs had stopped doing that and was restarted.