[lars_francke]

Agreed. And for me that has nothing to do with announcement vs. notes.

"We sped up new file creation, so you can now create a new file in under 20ms, a 100x speedup from v1.2."

No. You had a big bug. You fixed it. Excellent. When I'm affected by the bug I'd search for "deadlock" or "bug " in the announcement and this is hiding it behind marketing speak. I don't think that's honest. So for me the perfect announcements would be the red ones.

[mtlynch]

Thanks for reading!

>"We sped up new file creation, so you can now create a new file in under 20ms, a 100x speedup from v1.2."

>No. You had a big bug. You fixed it. Excellent. When I'm affected by the bug I'd search for "deadlock" or "bug " in the announcement and this is hiding it behind marketing speak. I don't think that's honest. So for me the perfect announcements would be the red ones.

I'm confused about how you'd know to search for those terms unless you were part of the dev team of that product.

A hang in the UI could just be the backend doing work in a way that's not optimized for UX. It's not necessarily a deadlock or a bug. Those are implementation details. It's not something a typical end-user can perceive just by using the software.

[sjsdaiuasgdia]

While you have a point for "deadlock", I'd say "bug" as a generic term for a software fault is fairly pervasive outside of the tech industry.

That said, there's an even better word IMO: "fix"

The wording you used for the new file speed-up feels like you're talking about a feature. The way it is worded you can technically read as a fix or a feature, but the way it's expressed feels like something greater than a bug fix occurred. As an end user, I would be wondering if I was going to experience a completely different flow to create a new file because that whole part of the software has been redone or something.

If it were up to me to write that entry on a release announcement, I'd probably say something like: "We fixed an issue that could cause a long delay when creating a new file."

Which is pretty close to your boring/dev-focused version, mostly dropping a few technical terms like "deadlock" and "UI". Calling it a fix makes it clear this isn't new functionality. If I am a user who has been tripping over this bug a lot, I'll recognize the description of the impact because it aligns to my experience of the product.

I don't need to come up with a contrived metric like "100x speedup". Is that even accurate for the situation being described, outside of edge cases? The boring version:

"Fixed a thread deadlock that froze the UI for up to two second when creating a new file."

From that, I take the implication that the problem does not necessarily happen every time a new file is created, and when it does, it does not necessarily take the full 2 seconds. That's being described as the worst-case scenario. For the average end user, are they going to actually experience a 100x speedup? Or are they going to create a new file and notice effectively nothing different, and wonder what the hell you're talking about?