Problem

One of the main problem that Batch Changes solves for users is making sure large campaigns with many changesets get merged efficiently, with minimal work from the batch change creator.
A key step to get there is to make sure repo owners are aware of the changes, in their context. Customers have a very heterogenous set of tooling and practices to make that happen: Jira, a custom tool, codeowners, custom systems.

Solution

We think that a good approach to solving this problem is to start by making it very easy for customers to integrate with their tooling. Then, depending on commonly build integrations, we can build some integrations ourselves either as customizations maintained by solutions engs, as extensions or into the core product.

That's why we think the reasonable first step is to build outgoing webhooks.

See a proposal here, discussions in https://github.com/sourcegraph/sourcegraph/issues/26790.

Solution validation

This approach is validated at a high level because:

• CEs customers have already built rough scripts to integrated with their system. Webhooks would considerably improve this. In particular, some customers use solutions that are unable to keep their ticketing system in sync with the status of changesets: it opens tickets, but never closes them which becomes pathological at 1k changeset scale.
• While every customer would prefer a native integration for their own system, they assess that making it easier to build their own integration is a great first step.
• This rough solution is in use at a customer and could be retired in favor of a better solution using webhooks.

Delivery plan

• Share and validate plan with other eng teams (RFC), so that we have a single outgoing hooks platform
• Validate solution with 3 customers
• Get feedback from implementation engineers (on using this to build custom workflows for key customers)