Updated release drafter config, added documentation (#1384)

Add information about release-labels
Add information to release process

Signed-off-by: Andreas Neumann <aneumann@mesosphere.com>

.github/release-drafter.yml

@@ -1,5 +1,5 @@
-name-template: 'kudo-v$NEXT_MINOR_VERSION'
-tag-template: 'v$NEXT_MINOR_VERSION'
+name-template: 'kudo-v$NEXT_MINOR_VERSION Draft'
+tag-template: 'v$NEXT_MINOR_VERSION-draft'
 categories:
   - title: '🚀 Highlights'
     labels:
@@ -9,6 +9,10 @@ categories:
       - 'release/breaking-change'
 change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
 template: |
+  This is a draft for the next release.
+
+  Please do not edit this file directly, use it as a template in the next release.
+
   ## Changes
 
   $CHANGES

CONTRIBUTING.md

@@ -90,6 +90,9 @@ This is a set of practices we try to live by when developing KUDO. These are jus
 - Since KUDO is developed in multiple timezones, try to keep the PR open for everyone to be able to see it (~24h, keep in mind public holidays)
 - We prefer squash commits so that all changes from a branch are committed to master as a single commit
 - Before you merge, make sure your commit title and description are meaningful. Github by default will list all the individual PR commits when squashing which are rarely insightful. We aim for a clean and meaningful commit history. 
+- Labels: If your PR includes either **breaking changes** or should get additional attention in the release, add one of these label:
+  - `release/highlight` For a big new feature, an important bug fix, the focus of the current release
+  - `release/breaking-change`  For anything that breaks backwards compatibility and requires users to take special care when upgrading to the new version
 
 - For a piece of work that takes >3-5 days, pair with somebody
 - When you pair with somebody, don't forget to appreciate their work using [co-authorship](https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors)

RELEASE.md

@@ -27,7 +27,7 @@ The official binaries for KUDO are created using [goreleaser](https://goreleaser
 1. Ensure you are logged into Docker hub and have rights to push to kudobuilder.
 1. Tag repo with expected release `git tag -a v0.2.0 -m "v0.2.0"`  && push tag `git push --tags`.
 1. Invoke goreleaser `goreleaser --rm-dist`.
-1. Update the GH release with Release highlights and a changelog.
+1. Update the GH release with Release highlights and a changelog. There is a draft that contains categorized changes since the last release, use this as a template. It provides categories for highlights and breaking changes, the issues there should get a more detailed description.
 1. Send an announcement email to `kudobuilder@googlegroups.com` with the subject `[ANNOUNCE] Kudo $VERSION is released`
 1. Create a PR against [kudobuilder/kudo.dev](https://github.com/kudobuilder/kudo.dev) with an according [blog post](https://kudo.dev/internal-docs/blog-index.html#release-posts).
 1. Run `./hack/generate_krew.sh` and submit the generated `kudo.yaml` to https://github.com/kubernetes-sigs/krew-index/.