Forked from kubernetes/enhancements#204 and other discussions.

We put our release notes here:
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md

The original release-note mechanism design and release changelog template were described here:
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release-notes.md

A decision about whether a PR should generate a release note was made merge-blocking in the PR workflow, as described here:
https://github.com/kubernetes/community/blob/master/contributors/devel/pull-requests.md#release-notes

We subsequently made it possible to both set the labels automatically from the PR template, if properly filled out, and created /release-note commands to enable non-maintainers to set the labels, as described here:

https://github.com/kubernetes/community/blob/master/contributors/devel/pull-request-commands.md#set-release-notes

We also subsequently developed the features repo and process, from which some of the release notes are created by hand, based on which features target the release.

It's clear that the release-note mechanism in the kubernetes repo is causing too much contributor friction, that most people don't know what deserves a release note (e.g., examples, tests, and build scripts shouldn't have release notes) or what would make a good release note, and that the features repo provides another potential mechanism for surfacing release notes.

** What is the purpose of release notes **

Release notes give our users a heads-up about what is coming when they install or upgrade to a particular release of Kubernetes.

They are not primarily for contributors to Kubernetes, who could look at the PRs associated with a particular git tag.

** What deserves a release note **

Any significant user- or admin-visible change. It could be an API change, a CLI change, a UI change, a configuration schema change, a behavioral change, a change in non-functional attributes such as efficiency or availability, availability of a new platform, advance warning about deprecation of a feature, etc.

Fixes of issues previously cited as Known Issues due to the breadth and/or severity of their impact also qualify, as do CVE fixes.

** What doesn't deserve a release note **

Not exhaustive:

• tests (e.g., Fix TestServiceAlloc flakes)
• examples
• build infrastructure
• fixes of unreleased bugs
• fixes of minor bugs
• ideally, incomplete/inaccessible features

** What should be in a release note **

• Clear, concise description of the change
  • Explicitly name affected API or configuration fields, CLI commands or flags, relevant feature, measured non-functional changes, etc., in user-visible terms (e.g., using json field names rather than Go field names)
  • State whether it was added, removed, changed, deprecated, advanced in maturity (alpha, beta, stable), etc.
  • Link to relevant user documentation about the feature or, if non-trivial actions are required, about the change itself (yes, docs shouldn't be an afterthought)
  • Make the information relevant to and actionable by admins or users, if necessary. (For example, Fix GCI mounter issue is not.)
• Appropriately categorized
  • Feature
  • Action required
  • Deprecation announcement
  • Other notable change, categorized by component or feature area (not by contributor concepts such as SIG or code repo)

We also need some way of reporting known issues left unaddressed in the release, and recommended versions of dependencies (e.g., etcd, container runtimes), along with their known issues.

cc @idvoretskyi @calebamiles @fejta @pwittrock