What is the preferred way to listen to the updates of a Wikibase.Cloud instance? (For instance, how is the Query Service updated?)
Currently EditGroups only supports listening to updates via the Wikimedia Event Service, which is obviously only available for Wikimedia projects and not for Wikibase.Cloud. Porting it to other Wikibase instances would likely involve adding support for updating via Recent Changes polling.
There is a ticket about this:
https://github.com/Wikidata/editgroups/issues/5

Quoting the Q2-Q3 usability research :

“After a week of [figuring out import], we realized that
we'd been missing some information and we had to
remove everything to do the import all over again,
knowing that the removal process was almost just as
long as the import process.”

That sounds like a need for a batch undo tool indeed!

Hello @Tarrow, I was happy to hear you on the Between the Brackets podcast, where you mentioned EditGroups, which reminded me of this ticket :)

I am currently working with @Arcstur to onboard him as a maintainer on EditGroups. I thought it could be a good occasion to brainstorm with you about where to take this project, to take WMDE's needs into account. We could perhaps have a call together to identify any hurdles in the way of using this tool with Wikibase.Cloud, and see if there is interest in tackling them from either side (from me, from @Arcstur, from you, or anyone else). The questions I am thinking about are:

• would you want to deploy a single EditGroups instance for all Wikibase.Cloud instances? In that case, adaptations would likely be required to make EditGroups multi-tenant (with a new notion of "Site", letting people view batches only from one site). This would also require changes to authentication, since logging in to the tool with OAuth is necessary to undo batches.
• would you want to pre-configure the EditGroups instance for the tools installed on Wikibase.Cloud (such as QuickStatements), so that edits made from those tools are directly tracked without further action from the user? Those tools are currently configured by adding entries in the database, similarly to the OAuth provider. It's probably fine for you to just add those database records automatically when creating the Wikibase.Cloud instance?
• how should EditGroups listen to edits made on Wikibase.Cloud (the question I asked above)? By polling recent changes? Via EventStream? Via Kafka directly?

Of course, I think it's also very good if WMDE uses this opportunity to consider how they want to support batch editing in MediaWiki / Wikibase at large, although I understand that there is probably no desire or capacity to come up with an alternative to the somewhat ad-hoc collection of external tools that currently support this use case. Which is fine by me :)

Both @Arcstur and I will be at the Wikimedia Hackathon and plan to do some onboarding together. If you or anyone from your team is also planning to attend, it could surely be a great opportunity to coordinate there.

Thanks @Pintoch. I would like to share that we at QuickStatements 3.0 are currently working to make it multi-tenant. Authentication seems for me the biggest challenge in QS3. In EditGroups, we would have to decide if a tool edits two+ wikibases we would add it twice in EG.

Batch editing support in the core Wikibase would be awesome indeed. Even tagging edits for a specific batch id and being able to query them back would make the EditGroups polling/regex searching unnecessary right? We could delegate the batch identification (if this becomes a feature) to the tool owners to identify that in their API call. Anyway, brainstorming very far into the future right now hahah.

In general, what prevents edit groups from being a MediaWiki extension?
It would generally IMO be very useful to have this as a generally installable thing, and accessible in the same UIs

I could hardly agree more, and it has indeed been suggested in T203557 shortly after the launch of this tool in 2018.