How do larger teams communicate what actually changed after a PR?
Posted by Upset-Tangelo-1615@reddit | ExperiencedDevs | View on Reddit | 30 comments
I’ve been trying to understand how this works across different teams.
In small projects, it’s usually straightforward you ship something, maybe drop a quick message or record a short demo if it’s important.
But once a team grows a bit like big MNC or mid sized companies, it feels like things get messy:
- PRs get merged
- features go live
- but outside engineering, people don’t always know what actually changed
Sometimes I see people record Looms or quick demos, but it doesn’t seem consistent. Other times it’s just PR descriptions or Slack messages, which aren’t always easy to follow if you’re not technical.
I’m curious how more experienced teams handle this in practice:
- How do you communicate changes after a PR is merged?
- Are demos recorded regularly, or only for larger features?
- Do PMs/designers actually follow PRs, or is there another layer of communication?
Tartiflan1@reddit
The thing that tends to work at mid-sized orgs is splitting the communication by audience before anyone has to read it. Engineers want the PR description and the diff. PMs want the ticket the PR closes and what is now possible for the user. Support wants the new steps or error messages they might see in tickets next week. GTM wants one sentence they can put in a release note or a customer email.
If one person tries to write "the PR description" for all four audiences simultaneously, every audience either gets too much or too little. What scales better is making the engineer responsible only for the technical layer, then a tiny automated piece that takes the merged PR title plus the linked ticket and drops a one-line entry into a channel that is monitored by non-eng people. Linear and a lot of the modern trackers already do this out of the box, and it turns the "how do I know what shipped" anxiety into a passive feed.
The Loom thing only works for features with a visible UI change. Half of what ships is schema migrations, refactors, infra tweaks, nobody needs a video of those, they just need the ticket to say "done" and the release notes to not pretend those changes existed.
Dear_Philosopher_@reddit
use ai
DamePants@reddit
In my experience some of them don’t communicate. This has predictable results like production fire drills trying to figure out what changed in the last month to cause the issue. It could be code, it be a feature flag, it could be a property, it could be a team sending unexpected data over. The team that owns the product will be held to the fire until the actual team that made bad assumptions and the change is found. Culprits are never held accountable and you won’t get automated testing until someone new comes in and decides they want to get ride of the old guard.
I have scars.
ninetofivedev@reddit
In the old days, someone would go through all the merge commits, which would link back to Jira tickets, and they'd summarize the changes.
Nobody likes doing this, so today, our team uses AI. We don't even care if it's accurate. Nobody reads the changelog, it's just something that management gets dopamine knowing it exists.
sebf@reddit
I still do it manually and it helps a lot to keep track of my work. Alway tie a MR / PR to a ticket and give the changes a title that helps management and product owner understanding what the code change does in term of business. It's also a good routine for mental health, I feel like things progress.
Really? I mean, if developers fill the changelog with meaningful information tied to business concerns, it looks like very useful to me. If they don't and use commits like "yet another fix lol", sure, it's worthless.
ninetofivedev@reddit
By and large, all of these sources of information are noise.
Commits shouldn't be a barrier for snapshotting work. For this reason, we squash/merge, and the only commit history that shows up in trunk a merge commit tied back to the Jira ticket.
Now what about that Jira ticket. It's hit or miss whether that will even have useful information in it. As much as we tell people to write up good tickets, not everyone does.
Now the changelog. Anything that is worth making our users aware of will have it's own priority for visibility.
Contrast that with the bullshit changelog that we produce that our management requires because they need to have a rollup of all the changes so they can point at something and say "See... Work is being done".
Fact of the matter is, most process, in the business world, is process for the sake of process. There are of course plenty of exceptions, but I would say by and large, most things we do are complete TPS.
CrappyInvoker@reddit
Writing a change log and mailing it to all whom may be concerned is standard practice no matter the size of your team. Just bundle your work items and provide a summary of them is essential for communication changes.
Empanatacion@reddit
I'd be worried nobody is going to read them and they'd just turn into a CYA document. Do you find them being meaningfully consumed in your company?
ninetofivedev@reddit
They make management smile. Is that meaningful?
pablosus86@reddit
WORN - Write Once, Read Never.
Upset-Tangelo-1615@reddit (OP)
Are those summaries enough for non-tech folks to understand what changed, or do they still need demos/screenshots sometimes?
BeyondLimits99@reddit
If they care they will ask questions.
It’s always better to have something rather than nothing.
developernoises@reddit
Its (usually) written at a level so that someone familiar with the product can read it. One bonus of this being a tracked file is PR reviewers can question unintelligible change log additions.
We do sprint reviews which involve stakeholders if a feature is worthy of demonstration. We take live questions at that time but you have to shoot down improvements veiled as questions. That time is just to demo what was done, not take on new input.
ChibiCoder@reddit
A lot of larger companies are using AI to produce "release notes" by analyzing the merged PRs that made it into the release cut branch. The notes are usually then curated and prioritized by a human, coordinating with a marketing team, who generate screenshots, illustrations, blog articles, etc. for the most important features.
Upset-Tangelo-1615@reddit (OP)
Curious about one specific case
If a UI change goes out (new flow or feature , etc), how do non-engineers(PM) usually see it?
Do you:
pablosus86@reddit
Thanks for giving a specific example.
The project manager, product owner, key stakeholders, etc absolutely need to see changes before they're released. That probably isn't reviewing a PR but some sort of demo, dogfooding, or internal testing.
It can be formal or informal and should be flexible for the scale and impact of a change, but IMO stakeholders need to say "yes, that's good to go".
throwaway_0x90@reddit
Release notes?
aseradyn@reddit
We do demos every two weeks. That's fairly raw updates from the Dev teams to the rest of the org (sales, support, etc)
The product managers also do a quarterly presentation where they highlight the most important/biggest feature adds. And they do a webinar for customers.
MaleficentCow8513@reddit
Versioned releases. Go on any GitHub project and you can see the changelog for every version which typically just includes commit headlines. That’s for interested parties but on large projects, that’s why good abstractions are importantly. My half of the project might only touch one piece of you half. I don’t need to know every single change across your half. I only care about the changes that affect my half. Good abstractions will make it so my half isn’t constantly having to adjust to changes on your half so most of the time I shouldn’t really have to care about what’s changing on your half
Upset-Tangelo-1615@reddit (OP)
Totally get that from an engineering perspective.
But for UI/product changes, do non-engineers actually go through those changelogs/commit headlines? Or do you usually end up showing it separately (demo, screenshots, etc)?
youafterthesilence@reddit
For us it depends. We are generally already working with the power users to do testing, so they get a summary of the change and test it and then they are the ones that will do a write up and flow down to the other users if it's something that will affect how they use it, and they'll do the screenshots or demos or training or whatever is needed.
MaleficentCow8513@reddit
One project I worked in the past did regular demos for end users. Only devs are looking at PRs and changelogs. PRs are all linked to jira tickets and that’s how managers track the progress. Large features and bugs will be composed of multiple tickets so managers can see what’s open, closed, in progress just by looking at jira. If you’re working an actual product, your users will typically already be familiar with your product and generally know what to look for and what to expect when you release new versions of your product
awofinc@reddit
For us it's automated release emails on every release with the changelog, most relevant for within engineering or product owners.
Regular stakeholder demos/sprint reviews to demo features and get feedback.
And then bigger releases/new features will get a company wide release email with screenshots/video.
Communicating widely after every PR doesn't always make sense, especially when you're working on a larger feature over some period of time behind a feature flag/access control.
PaulPhxAz@reddit
We added fields in our tickets that amount to "what does a dev want to tell people" and we have an auto-report on PR merge that gets all the notes together and publishes them to an internal changelog.
kitsnet@reddit
It is rarely when people need to know what was in your PR, unless it introduces or uncovers a bug.
People usually just care about the change requests your PRs have resolved.
Upset-Tangelo-1615@reddit (OP)
Makes sense for most PRs. But for user facing changes, do you guys rely only on the change request, or do people still need demos/screenshots to really get it?
kitsnet@reddit
Any user documentation shall be kept current. It can be updated later on a separate change request unless the changes are breaking someone's existing workflow.
In addition, you may have periodic updates for the existing user base, such as a weekly newsletter. The information for it is collected from the closed change request tickets.
Some big changes may warrant their own presentation. The presentation is better to be prepared in an offline format (which can be video, slides, or plain text) and there shall be some channel for Q&A.
developernoises@reddit
Keep a changelog and update it within the same PR. If you need to update people without repo access then this is the source of truth.
For specific guidance, we followed https://keepachangelog.com
developernoises@reddit
Its (usually) written at a level so that someone familiar with the product can read it. One bonus of this being a tracked file is PR reviewers can question unintelligible change log additions.
We do sprint reviews which involve stakeholders if a feature is worthy of demonstration. We take live questions at that time but you have to shoot down improvements veiled as questions. That time is just to demo what was done, not take on new input.
blacklig@reddit
When I worked at a mid size company we did stakeholder update meetings every 2 weeks for all of our projects, which was fun and pretty effective