🏃 PR Templates

.github/PULL_REQUEST_TEMPLATE/breaking_change.md

@@ -0,0 +1,11 @@
+---
+name: Breaking change (X)
+about: A breaking change to the API surface or expected behavior of this project. 
+
+---
+
+<!-- please add a :warning: (`:warning:`) to the title of this PR, and delete this line and similar ones -->
+
+<!-- What does this do, and why do we need it? -->
+
+<!-- Why does this have to be a breaking change (what else did you consider)? -->

.github/PULL_REQUEST_TEMPLATE/bug_fix.md

@@ -0,0 +1,11 @@
+---
+name: Bug fix (Z)
+about: A bug fix that doesn't otherwise change API surface
+
+---
+
+<!-- please add a :bug: (`:bug:`) to the title of this PR, and delete this line and similar ones -->
+
+<!-- What does this do, and why do we need it? -->
+
+<!-- What issue does this fix (e.g. Fixes #XYZ) -->

.github/PULL_REQUEST_TEMPLATE/compat_feature.md

@@ -0,0 +1,9 @@
+---
+name: Backwards-compatible feature (Y)
+about: A new feature that adds to the API surface or behavior, but doesn't break backwards compatibility
+
+---
+
+<!-- please add a :sparkles: (`:sparkles:`) to the title of this PR, and delete this line and similar ones -->
+
+<!-- What does this do, and why do we need it? -->

.github/PULL_REQUEST_TEMPLATE/docs.md

@@ -0,0 +1,9 @@
+---
+name: Documentation
+about: A change to the documentation of this repository
+
+---
+
+<!-- please add a :book: (`:book:`) to the title of this PR, and delete this line and similar ones -->
+
+<!-- What docs does this change, and why? -->

.github/PULL_REQUEST_TEMPLATE/other.md

@@ -0,0 +1,9 @@
+---
+name: Tests/Infra/Other
+about: A change to the tests in this repo, the utilities scripts, or some other piece of infrastructure tooling
+
+---
+
+<!-- please add a :running: (`:running:`) to the title of this PR, and delete this line and similar ones -->
+
+<!-- What does this do, and why do we need it? -->

VERSIONING.md

@@ -100,6 +100,10 @@ to match the PR. For instance, if you have a bugfix in with a breaking
 change, it's generally encouraged to submit the bugfix separately, but if
 you must put them in one PR, mark the commit separately.
 
+*Commits marked separately will be treated similiarly to a distinct PR by
+the cherrypick scripts*.  Therefore, only use them if you want the given
+commit to be considered separately.
+
 ### Commands and Workflow
 
 controller-runtime follows the standard Kubernetes workflow: any PR needs
@@ -126,17 +130,15 @@ will evaluate when to do a major release as it comes up.
 
 ### Exact Steps
 
-1. Generate release notes using the release note tooling (***TODO***)
-
-2. Add a release for controller-runtime on GitHub, using those release
-   notes
+1. (*if doing a minor or patch release*) Update the release-X branch with
+   the latest set of changes using the cherrypick tooling (***TODO***)
 
-3. Add a release for controller-tools on GitHub (folowing a similar
-   process for controller-tools release notes).
+2. Generate release notes using the release note tooling (***TODO***)
 
-4. Publish associated binaries and release tarballs (***TODO***)
+3. Add a release for controller-runtime on GitHub, using those release
+   notes, with a title of `vX.Y.Z`.
 
-5. Announce the release in `#kubebuilder` on Slack with a pinned message.
+4. Announce the release in `#kubebuilder` on Slack with a pinned message.
 
 ### Breaking Changes