Feature Request: Use developer-centric release notes

[LeoniePhiline]

• I have searched open and closed issues for duplicates

---

Bug Description

Someone is investing some creativity into the release notes - not only at app stores (where this is appropriate) but also on GitHub.

Honestly, these release notes are very effortful to read when you actually want to understand the content rather than "get a funny feel-good" feeling that is supposed to make random people install that update for their own good.

Please note that I don't want to offend anyone. There's certainly a good reason to write the release notes like that. However, maybe they need to be separated:

• Funny and cryptic in app stores, where signal must appear cool to attract non-technical users.
• Concise and clear on GitHub.

Steps to Reproduce

1. Go to https://github.com/signalapp/Signal-Desktop/releases
2. Try to understand what really has changed, was introduced, fixed etc.
3. See how difficult that is, because the funny text is much too cryptic.
   E.g. "Become a conversation artist. Use the new color selector to turn every chat into a masterpiece." -- what?

Actual Result:

Release notes don't help.

Expected Result:

Release notes help and offer information at a quick glance.

Platform Info

GitHub

[hiqua]

I think the example you mentioned is easy to understand once you've opened the app and look for the feature. It's fine if the feature is slightly cryptic when you read it in the release notes, as long as you know where to look in the app to understand it better.

To go back to your example, a reader can already understand that there's now some customization involving colors in chats. I don't think you need more than that, you can install the update to figure it out. What would you use a more sober description for?

[LeoniePhiline]

You want to know what changed before installing.
You might want to decide about the update by reading.
If you already installed, then maybe you don't need the release notes any more.

[hiqua]

You can only decide to postpone an upgrade for a relatively short amount of time (before it stops working), so your choices are limited anyway. There are also bug fixes at every release that are usually not highlighted in release notes but still benefit every user.

To be clear, I, like you, prefer clearer and sober descriptions; but I think release notes have little value for 99% of users beyond their marketing appeal, so I understand the current focus.

[klikevil]

• I have searched open and closed issues for duplicates

Bug Description

Someone is investing some creativity into the release notes - not only at app stores (where this is appropriate) but also on GitHub.

Honestly, these release notes are very effortful to read when you actually want to understand the content rather than "get a funny feel-good" feeling that is supposed to make random people install that update for their own good.

Please note that I don't want to offend anyone. There's certainly a good reason to write the release notes like that. However, maybe they need to be separated:

• Funny and cryptic in app stores, where signal must appear cool to attract non-technical users.
• Concise and clear on GitHub.

Steps to Reproduce

1. Go to https://github.com/signalapp/Signal-Desktop/releases
2. Try to understand what really has changed, was introduced, fixed etc.
3. See how difficult that is, because the funny text is much too cryptic.
   E.g. "Become a conversation artist. Use the new color selector to turn every chat into a masterpiece." -- what?

Actual Result:

Release notes don't help.

Expected Result:

Release notes help and offer information at a quick glance.

Platform Info

GitHub

Slightly off topic, but the become a conversation artist is what a large portion of the existing user base is outraged over, I don't mean to hijack your issue though: #5316

[chichilatte]

Just the latest few...

• "Feeling groggy when you wake up? Signal can now keep up better. When you resume your computer from sleep, Signal will reconnect faster."
• "Letting go can be hard, but our new custom disappearing timer can help you find a little more time to process those fleeting messages before they're gone forever."
• "Set a default disappearing message timer for new conversations, so you won't be reminded if you start off on the wrong foot."

It's advertising copy. Some of it almost pastiche, e.g. asking the customer a direct question. Recycling irrelevant clichés ("letting go can be hard", "start off on the wrong foot") is normal for copywriters, but seems so completely incongruous on github. I mean, starting off on the wrong foot is not why people use disappearing messages, but is a nice flight of fancy for a toiling copywriter tasked with fluffing up dull copy.

People don't normally read ad copy, or if they do it's skimmed at 100mph. Release notes though, lots of people (aka contributors) are used to reading them in detail. I came away feeling patronised and intelligence mildly insulted. Not a massive deal, but it's curious that this is the chosen approach.

[LeoniePhiline]

@klikevil Just delete your post. It’s spam.

[scottnonnenberg-signal]

I've changed this item to be what it really is - requesting us to add detailed developer-centric release notes to the repository. We did used to do that. But we probably won't return to it.

[HadetTheUndying]

I've recently updated signal and have absolutely not idea what's actually changed. "Some bugs were fixed" is not a good way of notifying package maintainers what's changing. Citing which major bugs and which commits address them would certainly be nice. Good work on fixing bugs, but it'd be nice to know if there was serious bugs that make upgrading immediately necessary and so on.

[Perkolator]

I've recently updated signal and have absolutely not idea what's actually changed.

Same here, last 9 days and what, 5 stable & 2 beta versions(!) released, with "bugs fixed" changelogs. Changelogs are important for everyone (though I have a feeling that in these IMO mad "auto-update everything silently in background without authorization" times, not many people even know that they have received an update, let alone that they would be even interested to read about the changes), but especially for those people that actually check out every change (=doing end-user testing for releases), it's frustrating to read lacking, poor (e.g. Vivaldi) or cryptic changelogs.

EDIT: I love it when developers actually are actively developing and releasing new versions, don't get me wrong, but what's with the recent flood of releases? Kind of makes me think that there has been some security issues (and that's why they do not want to disclose those yet in the changelogs?).

[IkerGimenez]

I liked the previous style of release notes better (developer centric). If I ran into an issue, I could keep track of when it was fixed, and also got to understand what new behaviors and features I could expect. The current style of "Fixed some bugs" is not useful at all. Obviously that is time that someone on the team has to spend documenting and publishing, but I believe that to be worth it.

[Penguin-Guru]

I like both. My personal preference would be to keep the creating descriptions, which do a pretty good job of connecting with both less and more technical users, and then include a simple link to the actual release notes here (or wherever they be posted).

[Perkolator]

I'm sorry but what is the point of releasing beta versions with "This update fixes a few bugs that were reported by our users. Thanks for your reports!" as the changelog? Betas are for testing. How do people test betas if you don't tell what has been changed?

Also, why do you just copy paste same changelog for many stable versions? For example recently 5.17.0, 5.17.1 and now latest 5.17.2 all has the same changelog. Why? What was changed? Don't you think that people would want to know? It's also for your benefit that end users (those that care) would be informed about changes.

EDIT: And yeah, forgot another thing, what's the point of releasing a beta and a stable version at the same time?