Update Release Notes Document to reflect PR boilerplate changes

1 files changed, 30 insertions, 3 deletions

diff --git a/contributors/guide/release-notes.md b/contributors/guide/release-notes.md
index bb2a5e82..404b8d04 100644
--- a/contributors/guide/release-notes.md
+++ b/contributors/guide/release-notes.md
@@ -5,8 +5,17 @@ slug: "release-notes"
 ---
 
 On the kubernetes/kubernetes repository, release notes are required for any pull
-request with user-visible changes, such as bug fixes, feature additions, and
-output format changes. Release notes are one of the most important reference
+request with user-visible changes, this could mean:
+
+##### - User facing, critical bug-fixes
+##### - Notable feature additions
+##### - Output format changes
+##### - Deprecations or removals
+##### - Metrics changes
+##### - Dependency changes
+##### - API changes
+
+Release notes are one of the most important reference
 points for users about to install or upgrade to a particular release of
 Kubernetes.
 
@@ -45,6 +54,10 @@ A release note needs a clear, concise description of the change. This includes:
 4. a link to relevant user documentation about the enhancement/feature
 
 ## Applying a Release Note
+slug: "adding-release-notes"
+
+On the kubernetes/kubernetes repository, release notes are required for any pull request with  [user-visible changes](#--user-facing-critical-bug-fixes).
+
 
 To meet this requirement, do one of the following:
 - Add notes in the release notes block, or
@@ -72,7 +85,21 @@ For pull requests that don't need to be mentioned at release time, use the `/rel
     NONE
     ```
 
-To see how to format your release notes, view the kubernetes/kubernetes [pull request template](https://git.k8s.io/kubernetes/.github/PULL_REQUEST_TEMPLATE.md) for a brief example. Pull Request titles and body comments can be modified at any time prior to the release to make them friendly for release notes.
+Your release note should be written in clear and straightforward sentences. Most often, users aren't familiar with the technical details of your PR, so consider what they _need to know_ when you write your release note.
+
+Some brief examples of release notes:
+
+```
+The deprecated flag --conntrack-max has been removed from kube-proxy. Users of this flag should switch to --conntrack-min and --conntrack-max-per-core instead. (#78399, @rikatz)
+
+The --export flag for the kubectl get command, deprecated since v1.14, will be removed in v1.18.
+
+Fixed a bug that prevents dry-run from being honored for the pod/eviction sub-resource. (#76969, @apelisse)
+```
+
+Pull Request titles and body comments can be modified at any time prior to the release to make them friendly for release notes.
+
+The release notes team maintains a [template](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/release-notes/relnotes-template.md) for Kubernetes Release notes that may help clarify whether or not your PR requires a release note. The most recent [Kubernetes Release notes](https://kubernetes.io/docs/setup/release/notes/) can also provide insight into the writing style for release notes.
 
 Release notes apply to pull requests on the master branch. For patch release branches the automated cherry-pick pull requests process (see the [cherry-pick instructions](/contributors/devel/sig-release/cherry-picks.md)) should be followed.  That automation will pull release notes from the master branch PR from which the cherry-pick originated. On a rare occasion a pull request on a patch release branch is not a cherry-pick, but rather is targeted directly to the non-master branch and in this case, a `release-note-*` label is required for that non-master pull request.