A merged pull request tells you what changed in the code. A useful customer announcement tells someone what they can do differently. The gap between those two things is where release communication gets difficult.
Here is a concrete example from building Mergelay. On 6 September 2026, we merged a pull request called “Improve Update notifications, review UX and team management.” It covers several changes, but we will follow just one: helping an operator find or request a fresh email link to review an Update.
The source change is real. The sample announcements below are editorial drafts written for this walkthrough, not a transcript of an AI generation or evidence of a customer email delivery.
1. Start with what the pull request actually supports
The PR adds notification status to an Update and lets an owner or admin request a fresh decision link. It also includes team invitations, role management and interface changes. Putting every item into the same announcement would make the reader work out which part matters to them.
We narrow the story to an identifiable situation: an Update is ready for review, but the original email is missing or its link has expired. The useful change is a visible status and an explicit way to request a fresh link.
There is a detail we must preserve: the email provider accepting a message does not prove that it reached an inbox. A draft saying “See whether your reviewer received the email” would claim more than the feature establishes.
Update-level notification status. An owner/admin can request a fresh decision link. The request is checked against the current Update version. Provider acceptance is distinct from inbox delivery.
2. Choose the reader before choosing the channel
For this change, the primary reader is the person managing review in Mergelay. It is not automatically every customer of the product being announced. Mergelay sends operator notifications about review, while a customer announcement is a separate piece of communication with its own audience and publication decision.
That distinction changes the wording. “Send a fresh decision link” is useful to an owner or admin. Someone without that permission needs to know who can help, rather than receive an instruction they cannot follow.
Before using any of these drafts, we would confirm that the feature is deployed for the intended workspace. A merge date is source provenance; it is not, by itself, a promise that every environment has the feature.
- Reader: the owner or admin coordinating an Update review.
- Situation: a review email cannot be found, or its link has expired.
- Action: open the Update, check its notification status, and request a fresh link if needed.
- Boundary: this does not automatically resend every old notification.
3. Write an email around the next useful action
The email does not need the PR title, implementation history or the list of database changes. It needs a recognisable problem, an accurate explanation and a next step. We would send it only if this improvement matters enough to the selected recipients to justify an interruption.
Subject: Need a fresh link to review an Update? If a Mergelay review email is missing or its link has expired, an owner or admin can request a fresh decision link from the Update page. Open the Update and check the Email notification section. It shows the notification status and provides the resend action. An email marked as accepted for sending is not a confirmation of inbox delivery. Use this when you need to get a review moving again.
4. Give the changelog and the team message different jobs
The changelog is a durable record that someone may find weeks later. It should name the capability and the relevant permission without assuming that the reader has an immediate problem. The internal team message can instead explain how to handle a support question.
Update review email status and resend Owners and admins can check notification status on an Update and request a fresh decision link when needed. The status distinguishes provider acceptance from delivery to a recipient’s inbox.
5. Keep the operational caveat in the internal note
An internal note can carry the detail a teammate needs to answer the next question. Copying the customer email into Slack would leave out that practical context. Conversely, sending a support procedure to every customer would add unnecessary weight.
If someone cannot find an Update review email, check the notification status with a workspace owner or admin. They can request a fresh decision link from the Update. Check the recipient and current Update before retrying. Provider acceptance is not proof of inbox delivery, and this change does not backfill old emails automatically.
6. Review the claim, the audience and the destination together
The final check is more than proofreading. Does the feature exist in the target environment? Can this recipient take the proposed action? Does the wording promise a delivery guarantee we cannot observe? Is this a release note to keep privately, a team message to send, or an email to customers?
Mergelay organises Changes into an Update with drafts for different channels, then supports review and publication to selected destinations. The useful habit is to keep the source change nearby while reviewing each draft. A polished sentence is not enough if it has lost a permission limit or added a guarantee.
For your next announcement, try this small exercise: choose one merged change, name one affected reader, and write one action they can take. Then decide whether that deserves an email, a changelog entry, an internal message, or no announcement at all.
Start with one meaningful change.
Bring your GitHub Changes into Mergelay and prepare an Update for review.
Start free