Dispatch is our product that makes it easy to keep everyone up to date with what's happening in Github. You can make your stakeholder comms plan executable by encoding who needs to know what, how, and when in a single organisation wide config file.
Currently Dispatch provides:
Over the past month or so we've released a whole bunch of improvements, most coming directly from customer requests. So here they are, along with some example use cases to highlight their value. A full look at all the Dispatch settings can be found in the Hecate Reference Configuration.
The most visible change has been a complete visual refresh of our emails.
Not only does it look better, but now the rollups include more useful metadata on each pull request to help you decide if it warrants further attention.
We've also added two new formatting keys for the rollup emails,
This lets you add a little bit of extra context to the rollup newsletter. One of our customers asked for this as they're using Dispatch to keep their internal customers appraised of all their releases and wanted to direct them back to the right team for any questions.
Our most popular feature to date has been the daily rollup and a few teams had asked whether we can support weekly rollups. We couldn't, but now we can!
Again, this feature is particularly useful for downstream stakeholder communications. As an Engineering Manager I don't recommend waiting a whole week to find out what merged, but it's a cadence that works nicely for a lot of other teams.
We've added a few other fine-grained scheduling controls,
day_of_week. Dispatch has been timezone aware since launch, but rollups had until now been hardcoded to go out at 8am each day. That remains our default setting but you can now choose the hour of your email, and day if you're using the weekly rollup feature.
As more and more customers came on board we learned that workflows around labels were really common and we've added some features to support them.
First of all we added a new
trigger option which will let you set up instant notifications when a label is added to a pull request.
One customer requested this feature to streamline the process between the development and documentation teams. When a feature is worked on that requires documentation changes or customer outreach a label of "Needs Documentation" or similar is added, and the documentation team picks up that work. Previously lots of work was missed, but now the team knows about these pull requests as soon as they're labeled.
There are new matching options too:
exluding_labels, which work across all notification types and work pretty much as you'd expect. The exclude list is particularly handy for stakeholder rollups, allowing you to opt out certain pull requests (like infrastructure work) that a downstream team might not be interested in.
If you're a current customer you can try any of these new features out right now, just update your
hecate.yml file, wherever it is you stored it.
If you're yet to give it a try, sign up here for a 7 day free trial.