Thelounge: Improve our change log format

[astorije]

Our change log currently follows (or tries to follow) recommendations from http://keepachangelog.com/.

I was told recently that the current format is not very user-friendly (in our case, "user" means both the client user and the server administrator, as they both "use" our project, even though they have different interests when looking at the change log) as the Added/Fixed/... is a dump of all merged PR, sometimes massaged, and that some actually refer to improvements or fixes introduced within the same release, so it's not a "change" by definition.
Also, it was pointed that some entries refer to internal changes and therefore should not be displayed, but I'd argue that a change log is also useful for contributors and developers, to whom these can be useful.

I have tried to introduce releases with a short description (done in the last 7 releases), but I understand that this might not be enough.

This thread attempts to start a discussion on how we can improve this. Note that writing a change log is actually very much time consuming, time which which would be better spent at reviewing open PRs, so my one requirement would be that any proposed solution does not increase this time, at worst, or actually reduces it at best.
I don't think any automated solution (and there are some out there so I'm thinking someone will recommend one 😄) will be appropriate, as they tend to generate lists based on merged PRs and closed issues, which would bring us back to the current problem.

To illustrate your suggestions, I think the best way is to take an existing release as an example and to propose an altered, improved version, in a way that it can be applied to other releases later on.

_If this issue is unclear, keep in mind that it's 2AM for me right now, so be gentle and ask for clarifications if needed._ 😅

[xPaw]

Stuff like updating packages or changing CI configs are not very interesting changelog entries. If you do want to keep these, at least put them in their own separate Other section so the real fixed/changed/added sections are easier to read.

[astorije]

Fair point.
For the CI configs, 1:1 refactors, etc., I would add a "Internals" section or the like. However, package updates could go either in these, or in more appropriate section: for example, we often bump irc-framework to fix a bug (that's what we've been doing the last 3 bumps at least.

On a different note, when giving a digest of the changes at the top, I would split things in 2 sections (what I've been doing naturally anyway): changes/additions/bugfixes that affect the administrator, and changes/additions/bugfixes that affect the user.

[MaxLeiter]

Would an "At a glance" section be beneficial? That is, visible changes on the client for "end users", and a separate "backend" section for administrators? (there's probably changes that don't fall into either of those categories but I can't think of them atm)

EDIT: just read the second half of @astorije's comment; that's what I think would work best

[astorije]

Is it worth having a "Documentation" section?
It would mostly be about the README for now (plus maybe CONTRIBUTING, CHANGELOG, ...), but if somehow we manage to move the docs part of the website to this repo (using that cool /docs directory support GitHub recently added to GitHub Pages), that could become meaningful.