←back to thread

69 points mtlynch | 2 comments | | HN request time: 0.001s | source
Show context
deanebarker ◴[] No.44378079[source]
Actually, I don't love this. 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.

"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?

replies(4): >>44378248 #>>44378305 #>>44378659 #>>44378942 #
mtlynch ◴[] No.44378305[source]
Author here.

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...

replies(1): >>44378370 #
Milpotel ◴[] No.44378370[source]
> 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.

replies(2): >>44378448 #>>44378456 #
1. mtlynch ◴[] No.44378448[source]
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.

replies(1): >>44379613 #
2. tempodox ◴[] No.44379613[source]
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.