> probleemoplossingen en prestatieverbeteringen
love 'bugfixes and performance improvements' in dutch
Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
61–70 of 127 posts
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#62The problem is often the "bugfixes and performance improvements" are a list of 60 things, and for almost all users "there are less crashes and it is faster" is all they would want to know. How many users want to read (OK, possibly people here) "On some versions of glibc, the 32-bit specialisation of memcpy which used SSE2 instructions had a bug when the memory being copied crossed the 2GB boundary, so in that case we…
I think the key is describing the user-facing effects and impact. This means knowing your users (are they developers, IT or highly technical? Do they automatically or manually update quickly, or do they take time to evaluate before rolling out updates?). It's a way to convey continuing value to users and convince them it's worthwhile to keep paying, and get motivated to get the update. I'd try to change what you wrot…
> but for subscription/"enterprise" software it's definitely one of the differences between "great" and merely acceptable (or worse).
I couldn’t agree more.
I tried writing more informative but easy to digest release notes when a couple noisy users mentioned at a trade show that they wanted to know more about our bug-fixing efforts.
To my surprise, we got a huge volume of communications from our users that they loved our new release note style and to keep it up.
It takes us about 1 hour / release to write. We release small changes weekly and large changes monthly to about 1mm MAUs.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#63The problem is often the "bugfixes and performance improvements" are a list of 60 things, and for almost all users "there are less crashes and it is faster" is all they would want to know. How many users want to read (OK, possibly people here) "On some versions of glibc, the 32-bit specialisation of memcpy which used SSE2 instructions had a bug when the memory being copied crossed the 2GB boundary, so in that case we…
There’s also a mitigating liability aspect to this. If you start providing minutiae detail, you may start revealing pretty big faults that have escaped to prod. People question the safety of your product and now you’re open to lawsuit or at least micromanaged by some unforgiving end-customers. To cope, you start to not fix certain problems so you won’t have to report the bugs or you start lying what the bugs were. I’…
Has there ever been a lawsuit in which a company was held liable for bugs despite the usual disclaimer?
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#64As a startup we write fairly detailed changelogs weekly [1]. For us it has been a major way to communicate all the new features and fixes as they come available to users. It’s also a good way for the team to celebrate their accomplishments. I was surprised to learn it also had helped with investors and generally marketing.
Usually the person who was a major contributor to the highlighted feature of the week writes the changelog and then we look through our PRs to add anything that could be interesting. We don’t include things like “migrated x” “upgraded library x” if there is no visible benefit for there.
Wrote about the lessons here: https://link.medium.com/9YuBV3dUIcb
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#65The reason these bigger apps just put "Bugfixes" and "Performance Improvements" in their changelog is because when you have many teams contributing to the software not only through actual code editing but also feature flagging what features go out on what release, rollback policies etc this becomes a nightmare to fill in. Doubly so when different users are receiving different experiences. The article says at the end:…
Difficulty of task never excuses doing a lazy job. Especially if you hope people will pay you.
If it's worth doing, it's worth doing half-assed.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#66The problem is often the "bugfixes and performance improvements" are a list of 60 things, and for almost all users "there are less crashes and it is faster" is all they would want to know. How many users want to read (OK, possibly people here) "On some versions of glibc, the 32-bit specialisation of memcpy which used SSE2 instructions had a bug when the memory being copied crossed the 2GB boundary, so in that case we…
I think the author of the article brings up a good point regarding this, though. If you're a non-technical user, you're not going to read it at all. You might update, you might not, but you're not going to look through the list of changes.
If you're a technical user, you know it's unlikely that update == "more crashes and slower load times" so saying the opposite isn't helpful, and a list of things might be helpful.
So as a user of an app you probably fall into one of 3(ish) categories:
1. You read the changelog and something is relevant to you.
2. You read the changelog and nothing is relevant to you.
3. You don't know what the changelog is.
Listing the bugs that are fixed helps some of these groups. "Bugfixes and performance improvements" is a given, and helps no one.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#67Earlier quoted context omitted.
Aren't the flaws the sources of the liabilities?
Sure, but most people accept that flaws are inevitable. It's not practical (or profitable) for most industries to produce totally flaw-free software. If you can't stop the flaws, the next best option is to shield yourself from those flaws harming your financial well being.
Having a changelog does not make you more open to lawsuits.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#68The problem is often the "bugfixes and performance improvements" are a list of 60 things, and for almost all users "there are less crashes and it is faster" is all they would want to know. How many users want to read (OK, possibly people here) "On some versions of glibc, the 32-bit specialisation of memcpy which used SSE2 instructions had a bug when the memory being copied crossed the 2GB boundary, so in that case we…
There’s also a mitigating liability aspect to this. If you start providing minutiae detail, you may start revealing pretty big faults that have escaped to prod. People question the safety of your product and now you’re open to lawsuit or at least micromanaged by some unforgiving end-customers. To cope, you start to not fix certain problems so you won’t have to report the bugs or you start lying what the bugs were. I’…
Let’s stop condoning covering up incompetence.
If you fuck up, admit to it, fix it and learn from it.
If you fuck up bad enough that someone had a good case against you then you should make them whole and use the opportunity as a wake-up call to make sure this never happens.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#69Maybe like a couple bullet points, nothing too technical, but it’s a good spot to talk to your customers and make them happy.
It does depend on the product though. I can see a developer tool maybe even just going so far as to putting out their internal change log, but for other customer segments, it’s best to keep it short and (hopefully) funny
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#70Worst offenders aren't even those. Some go as far as an 'Information not provided by developer', and the worst of them all - Netflix's 'You just worry about what to watch next.'. Irritates me to no end, I now only update manually and if there's no apparent benefit I just don't. Saved me from seeing some apps' changing icons into something awful, or hostile UX redesigns. It was a shame when Discord, who used to have some of the very best changelogs, turned into this practice.