> but I generally think the release announcement does a better job at showcasing features.
I'm all in skimming some bullet points on release notes but reading whole paragraphs for trivial announcements (like "Create events 10x faster") is an absolute no-go and wasted developer time in most cases.
When I read that, I feel like I am being sold to and I need to decode it to find out what the actual change is.
I’m generally in agreement that you should write release announcements in terms that relate to what the end-user is trying to accomplish and not just a mechanical diff, but this goes approximately 100% too far.
I notice that you said "wasted developer time" rather than "user time" so maybe this is the difference?
I think too many developers write about their software as if the readers are other developers, especially developers with high context into the software. But for most software, the users are not developers, and they generally have much less context than the developers working on it.
I can understand how "Add a duplicate event button" is sufficient if I'm communicating with another developer on an open-source project, but I think the typical end-user requires more explanation of why that button is useful and what they can do with it.
> I notice that you said "wasted developer time" rather than "user time" so maybe this is the difference?
Maybe both? It's wasted developer time because someone has to curate the list and write it up for an audience that does not exist or is equivalent to your own marketing and sales department?
You don't have to ramp up marketing to 11 to write release notes that users can understand. Those are users of software that they already have and use. They will know what the changes mean for them.
I'm all in skimming some bullet points on release notes but reading whole paragraphs for trivial announcements (like "Create events 10x faster") is an absolute no-go and wasted developer time in most cases.