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