If you write release notes for software with a lot of users: what makes you go generic? I assume there's a reason past laziness and I'd rather hear it from someone who's made the call.
If you write release notes for software with a lot of users: what makes you go generic? I assume there's a reason past laziness and I'd rather hear it from someone who's made the call.
You've reached the end!
Jemaclus•1h ago
From my personal experience, the context of the fix lives in a dozen different places: the ticket, the code, the commit message. And now I need to document it a fourth time? From a dev perspective, the value just isn't there beyond a vague "fixed zoom issue for #1355," because you can go look at ticket 1355 and see the context, and look at the diff to see what changed.
From a dev's perspective, I'm documenting the same thing for the fourth time, except this time, perhaps, I have to think about the information from the perspective of a customer or non-technical person, and then decide how much information and detail is appropriate, and so on and so forth. I wouldn't say it's laziness, per se, as much as it's more work, and we have a lot of other things to do.
Also, let's be real: how many people read release notes? My boss doesn't, the CEO doesn't. Release note quality doesn't show up on my performance reviews. Customers don't leave Yelp reviews or App Store reviews because my release notes were bland. There's no career incentive for me to do "better." Maybe that should change, but that's the reality.
So the question comes back to you: what value are you seeking from release notes, and what level of detail makes sense to you?