chore: Finetune automatic changelogs

[alimpens]

No description provided.

[VincentSmedinga]

I suggest using a list and moving the empty line to make this easier to scan:

Suggested change

	In our PR titles, we specify whether a change is a fix (patch), a new feature (minor) or a breaking change (major).
	If you want to make a change without triggering a new release, use the `chore` prefix.
	Note: Only use this prefix when updating development dependencies, changing configuration or updating documentation which isn't about a component.
	For refactors, regular dependency updates or updates to documentation about components, use the `fix` prefix.
	The titles of our PR’s specify whether a change is:
	* a `chore`, which doesn’t trigger a release
	* a `fix`, resulting in a patch release,
	* a new feature (`feat`), a minor release, or
	* a breaking change (`feat!`), a major release.
	Use the `chore` prefix when updating development dependencies, changing configuration or updating documentation which isn't about a component.
	For refactors, regular dependency updates or updates to documentation about components, use the `fix` prefix.

[VincentSmedinga]

Reading the last two sentences makes me wonder whether we should introduce two different prefixes for dependencies (or something more general to include e.g. CI) and documentation after all.

Documentation is an essential part of a library; we shouldn’t swipe new non-component docs under the rug.

And an actual bug fix is something different than a dependency update. Consumers will be very interested in the former, not so much in the latter.

[alimpens]

Documentation is an essential part of a library; we shouldn’t swipe new non-component docs under the rug.

Hm, do you think a change to say coding-conventions.md is relevant for the consumers of our packages? Same goes for dev dependencies, if it doesn't change the code or docs we ship, it's irrelevant, no?

And an actual bug fix is something different than a dependency update. Consumers will be very interested in the former, not so much in the latter.

True, but semver doesn't really offer room for that distinction I think. Any change to the code we ship which doesn't add a feature or breaks backwards compatibility is considered a patch release.

[VincentSmedinga]

Hm, do you think a change to say coding-conventions.md is relevant for the consumers of our packages? Same goes for dev dependencies, if it doesn't change the code or docs we ship, it's irrelevant, no?

Oh no, not the ‘internal’ docs. I was thinking of pages like our design guidelines on grid, typography etc.

True, but semver doesn't really offer room for that distinction I think. Any change to the code we ship which doesn't add a feature or breaks backwards compatibility is considered a patch release.

Certainly. I was envisioning the change log, where I think separate headings or lists for documentation and dependencies might be in order. How about that?

[alimpens]

Oh no, not the ‘internal’ docs. I was thinking of pages like our design guidelines on grid, typography etc.

Those aren't part of packages we publish, so changes to them won't trigger a release anyway. Only changes to files in packages/* and proprietary/* trigger a release.

Certainly. I was envisioning the change log, where I think separate headings or lists for documentation and dependencies might be in order. How about that?

Yeah, definitely, we could use scopes for that. We would need to decide on a list of scopes to make them meaningful, I think. The proposed change in this PR already takes care of a part of that, Dependabot PRs should get a scope of deps

[VincentSmedinga]

Those aren't part of packages we publish

Oh yeah, of course.

we could use scopes for that

Great.