"Added 'duplicate' button to the event menu" is kind of exactly what I want to read.
I don't know -- maybe have both kinds? A simple, bare-bones set, and then an... "embellished" set?
Thanks for reading!
>To me, the examples in red are much more helpful -- they explain, in bare terms, what was actually done. The examples in green feel like a marketing exercise to me. Like they're trying to wrap or obscure clear writing in something to obfuscate it.
Oh, interesting. That surprises me. I think there are some cases where I want the short version (e.g., if I'm just looking for breaking changes or fixes to minor annoyances), but I generally think the release announcement does a better job at showcasing features.
Out of curiosity, do you find the example changelog-style announcement[0] more useful than the Figma's example release announcement[1]?
>I don't know -- maybe have both kinds?
Yes, absolutely. They're not mutually exclusive.
Whenever I've published a release announcement, I also link to a changelog, which is the bullet point list of changes. I think the changelog should also be more user-oriented than most currently are, but I think the changelog is the right place for an exhaustive list of anything that users might want to know about the new version.
[0] https://refactoringenglish.com/chapters/release-announcement...
[1] https://help.figma.com/hc/en-us/articles/23954856027159-Navi...
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.
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.
