Release note workflow

[jakirkham]

Currently we label PRs without release notes. Though wonder if we should actually have a failing CI check for this. That might improve visibility and avoid accidentally merging with out release notes. Though unsure how much we want to enforce having release notes (maybe there are cases we don't want to bother with them?). Thoughts?

[jakirkham]

cc @Saransh-cpp @MSanKeys963 @joshmoore

[Saransh-cpp]

maybe there are cases we don't want to bother with them?

Yes, cases like minor spelling fix maybe? It won't be nice to fail the check on a PR containing a single spelling fix.

[joshmoore]

@DimitriPapadopoulos can correct me, but the criterion he seems to use is "does it touch real code?"

[DimitriPapadopoulos]

Good question. I do not really have a formal definition.

Perhaps I would typically not include whatever does not impact functionality, either for ends users or developers, or is not related to a specific release. For example, I would leave out:

• spelling fixes, unless they are important to end users or developers (for example "use rm -ri to avoid data loss" instead of "use rm -rf to avoid data loss" in a user guide)
• running black to format the source code
• changes to CI, perhaps because such changes are usually enforced immediately and are therefore not tied to a specific release, rather to a specific commit
• changes to the URL in FUNDING.yml, unless you do want end users to notice this FUNDING.yml file 😄

I would include some changes not related to actual code:

• change of license, because that does impact end users
• reworked documentation
• changes in data used for testing