devel/sig-release: Markdown linting

Signed-off-by: Stephen Augustus <saugustus@vmware.com>

3 files changed, 336 insertions, 332 deletions

diff --git a/contributors/devel/sig-release/cherry-picks.md b/contributors/devel/sig-release/cherry-picks.md
index 72ef7afb..76a296f1 100644
--- a/contributors/devel/sig-release/cherry-picks.md
+++ b/contributors/devel/sig-release/cherry-picks.md
@@ -2,88 +2,92 @@
 
 This document explains how cherry-picks are managed on release branches within
 the kubernetes/kubernetes repository.
-A common use case for this task is backporting PRs from master to release 
+A common use case for this task is backporting PRs from master to release
 branches.
 
--   [Prerequisites](#prerequisites)
--   [What Kind of PRs are Good for Cherry-picks](#what-kind-of-prs-are-good-for-cherry-picks)
--   [Initiate a Cherry-pick](#initiate-a-cherry-pick)
--   [Cherry-pick Review](#cherry-pick-review)
--   [Searching for Cherry-picks](#searching-for-cherry-picks)
--   [Troubleshooting Cherry-picks](#troubleshooting-cherry-picks)
--   [Cherry-picks for unsupported releases](#cherry-picks-for-unsupported-releases)
-
----
+- [Prerequisites](#prerequisites)
+- [What Kind of PRs are Good for Cherry-Picks](#what-kind-of-prs-are-good-for-cherry-picks)
+- [Initiate a Cherry-pick](#initiate-a-cherry-pick)
+- [Cherry-pick Review](#cherry-pick-review)
+- [Searching for Cherry-picks](#searching-for-cherry-picks)
+- [Troubleshooting Cherry-picks](#troubleshooting-cherry-picks)
+- [Cherry-picks for unsupported releases](#cherry-picks-for-unsupported-releases)
 
 ## Prerequisites
- * [Contributor License Agreement](http://git.k8s.io/community/CLA.md) is
+
+- [Contributor License Agreement](http://git.k8s.io/community/CLA.md) is
    considered implicit for all code within cherry-pick pull requests,
    **unless there is a large conflict**.
- * A pull request merged against the master branch.
- * [Release branch](https://git.k8s.io/release/docs/branching.md) exists.
- * The normal git and GitHub configured shell environment for pushing to your
-   kubernetes `origin` fork on GitHub and making a pull request against a 
+- A pull request merged against the master branch.
+- [Release branch](https://git.k8s.io/release/docs/branching.md) exists.
+- The normal git and GitHub configured shell environment for pushing to your
+   kubernetes `origin` fork on GitHub and making a pull request against a
    configured remote `upstream` that tracks
    "https://github.com/kubernetes/kubernetes.git", including `GITHUB_USER`.
- * Have `hub` installed, which is most easily installed via `go get
+- Have `hub` installed, which is most easily installed via `go get
    github.com/github/hub` assuming you have a standard golang development
    environment.
 
-
 ## What Kind of PRs are Good for Cherry-Picks
 
 Compared to the normal master branch's merge volume across time,
 the release branches see one or two orders of magnitude less PRs.
 This is because there is an order or two of magnitude higher scrutiny.
-Again the emphasis is on critical bug fixes, eg:
- * Loss of data
- * Memory corruption
- * Panic, crash, hang
- * Security
+Again the emphasis is on critical bug fixes, e.g.,
+
+- Loss of data
+- Memory corruption
+- Panic, crash, hang
+- Security
 
 If you are proposing a cherry-pick and it is not a clear and obvious
 critical bug fix, please reconsider.  If upon reflection you wish to
-continue, bolster your case by supplementing your PR with, eg:
-
- * A GitHub issue detailing the problem
+continue, bolster your case by supplementing your PR with e.g.,
 
- * Scope of the change
+- A GitHub issue detailing the problem
 
- * Risks of adding a change
+- Scope of the change
 
- * Risks of associated regression
+- Risks of adding a change
 
- * Testing performed, test cases added
+- Risks of associated regression
 
- * Key stakeholder SIG reviewers/approvers attesting to their confidence in the
-   change being a required backport
+- Testing performed, test cases added
 
- * If the change is in cloud-provider-specific platform code (which is in the
-   process of being moved out of core Kubernetes), describe the customer impact,
-   how the issue escaped initial testing, remediation taken to prevent similar
-   future escapes, and why the change cannot be carried in your downstream
-   fork of the Kubernetes project branches.  It is critical that our full
-   community is actively engaged on enhancements in the project.  If a
-   released feature was not enabled on a particular provider's platform, this
-   is a community miss that needs to be resolved in the master branch for
-   subsequent releases.  Such enabling will not be backported to the patch
-   release branches.
+- Key stakeholder SIG reviewers/approvers attesting to their confidence in the
+  change being a required backport
 
+- If the change is in cloud-provider-specific platform code (which is in the
+  process of being moved out of core Kubernetes), describe the customer impact,
+  how the issue escaped initial testing, remediation taken to prevent similar
+  future escapes, and why the change cannot be carried in your downstream
+  fork of the Kubernetes project branches.  It is critical that our full
+  community is actively engaged on enhancements in the project.  If a
+  released feature was not enabled on a particular provider's platform, this
+  is a community miss that needs to be resolved in the master branch for
+  subsequent releases.  Such enabling will not be backported to the patch
+  release branches.
 
 ## Initiate a Cherry-pick
- * Run the [cherry-pick 
-   script](https://git.k8s.io/kubernetes/hack/cherry_pick_pull.sh).
-   This example applies a master branch PR #98765 to the remote branch
-   `upstream/release-3.14`: `hack/cherry_pick_pull.sh upstream/release-3.14
-   98765`
-   * Be aware the cherry-pick script assumes you have a git remote called 
-   `upstream` that points at the Kubernetes github org.
-   Please see our [recommended Git workflow](https://git.k8s.io/community/contributors/guide/github-workflow.md#workflow).
-   * You will need to run the cherry-pick script separately for each patch release you want to cherry-pick to.
-
- * Your cherry-pick PR will immediately get the `do-not-merge/cherry-pick-not-approved` label. 
-   [Normal rules apply for code merge](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md#tldr),
-   with some additional caveats outlined in the next section of this document.
+
+- Run the [cherry-pick script](https://git.k8s.io/kubernetes/hack/cherry_pick_pull.sh)
+  This example applies a master branch PR #98765 to the remote branch
+  `upstream/release-3.14`: `hack/cherry_pick_pull.sh upstream/release-3.14
+  98765`
+
+  - Be aware the cherry-pick script assumes you have a git remote called
+    `upstream` that points at the Kubernetes github org.
+
+    Please see our [recommended Git workflow](https://git.k8s.io/community/contributors/guide/github-workflow.md#workflow).
+
+  - You will need to run the cherry-pick script separately for each patch
+    release you want to cherry-pick to.
+
+- Your cherry-pick PR will immediately get the
+  `do-not-merge/cherry-pick-not-approved` label.
+
+  [Normal rules apply for code merge](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md#tldr),
+  with some additional caveats outlined in the next section of this document.
 
 ## Cherry-pick Review
 
@@ -101,46 +105,48 @@ or include in a comment the `/release-note-none` command.
 Cherry-pick pull requests are reviewed slightly differently than normal
 pull requests on the master branch in that they:
 
- * Are by default expected to be `kind/bug` and `priority/critical-urgent`.
-
- * Milestones must be set on the PR reflecting the milestone for the target
-   release branch (for example, milestone v1.11 for a cherry-pick onto branch
-   release-1.11). This is normally done for you by automation.
-
- * Have one additional level of review in that they must be approved specifically
-   for cherry-pick by branch approvers.
-
-   The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
-   will triage PRs targeted to the next .0 minor release branch up until the 
-   release, while the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager) 
-   will handle all cherry-picks to patch releases.
-
-   The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
-   or the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
-   are the final authority on branch approval by removing the `do-not-merge/cherry-pick-not-approved`
-   label and triggering a merge into the target branch.
-
-   The team scrubs through incoming cherry-picks on at least a weekly basis, daily during
-   burndown ahead of a .0 release.  Ahead of point releases, reminders of the
-   cherry-pick deadline will be sent out to the community.  Cherry-pick PRs are
-   often metered into the release branches to give more deliberate CI signal across
-   changes.  For this reason your cherry-pick must be ready to merge ahead of
-   the cherry-pick deadline, but those candidates may be merged during the days
-   between the deadline and release.
-
-   Open cherry-pick PRs which do not land in the current release will
-   continue to be tracked by the team for consideration for inclusion in a next
-   patch release.
-
-   If you are concerned about the status of your cherry-pick, err on the
-   side of overcommunicating and reach out to the branch reviewer(s):
-
-   * During code freeze or after code thaw and ahead of a .0 release, to get attention on a cherry-pick by the current
-     release team members see the [appropriate release folder](https://git.k8s.io/sig-release/releases)
-     for the target release's team contact information. You may cc them with
-     `@<githubusername>` on your cherry-pick PR.
-
-   * For prior branches, check the [patch release schedule](https://git.k8s.io/sig-release/releases/patch-releases.md), which includes contact information for the patch release team.
+- Are by default expected to be `kind/bug` and `priority/critical-urgent`.
+
+- Milestones must be set on the PR reflecting the milestone for the target
+  release branch (for example, milestone v1.11 for a cherry-pick onto branch
+  release-1.11). This is normally done for you by automation.
+
+- Have one additional level of review in that they must be approved
+  specifically for cherry-pick by branch approvers.
+
+  The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
+  will triage PRs targeted to the next .0 minor release branch up until the
+  release, while the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
+  will handle all cherry-picks to patch releases.
+
+  The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
+  or the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
+  are the final authority on branch approval by removing the
+  `do-not-merge/cherry-pick-not-approved` label and triggering a merge into the
+  target branch.
+
+  The team scrubs through incoming cherry-picks on at least a weekly basis,
+  daily during burndown ahead of a .0 release. Ahead of point releases,
+  reminders of the cherry-pick deadline will be sent out to the community.
+  Cherry-pick PRs are often metered into the release branches to give more
+  deliberate CI signal across changes. For this reason your cherry-pick must be
+  ready to merge ahead of the cherry-pick deadline, but those candidates may be
+  merged during the days between the deadline and release.
+
+  Open cherry-pick PRs which do not land in the current release will
+  continue to be tracked by the team for consideration for inclusion in a next
+  patch release.
+
+  If you are concerned about the status of your cherry-pick, err on the
+  side of overcommunicating and reach out to the branch reviewer(s):
+
+  - During code freeze or after code thaw and ahead of a .0 release, to get
+    attention on a cherry-pick by the current release team members see the
+    [appropriate release folder](https://git.k8s.io/sig-release/releases) for
+    the target release's team contact information. You may cc them with
+    `@<githubusername>` on your cherry-pick PR.
+  - For prior branches, check the [patch release schedule](https://git.k8s.io/sig-release/releases/patch-releases.md),
+    which includes contact information for the patch release team.
 
 ## Searching for Cherry-picks
 
@@ -148,34 +154,42 @@ pull requests on the master branch in that they:
 
 - [A sample search on kubernetes/kubernetes pull requests that are labeled as `do-not-merge/cherry-pick-not-approved`](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Ado-not-merge%2Fcherry-pick-not-approved)
 
-
 ## Troubleshooting Cherry-picks
 
-Contributors may encounter some of the following difficulties when initiating a cherry-pick.
+Contributors may encounter some of the following difficulties when initiating a
+cherry-pick.
 
-- A cherry-pick PR does not apply cleanly against an old release branch.
-In that case, you will need to manually fix conflicts.
+- A cherry-pick PR does not apply cleanly against an old release branch. In
+  that case, you will need to manually fix conflicts.
 
-- The cherry-pick PR includes code that does not pass CI tests.
-In such a case you will have to fetch the auto-generated branch from your fork, amend the problematic commit and force push to the auto-generated branch.
-Alternatively, you can create a new PR, which is noisier.
+- The cherry-pick PR includes code that does not pass CI tests. In such a case
+  you will have to fetch the auto-generated branch from your fork, amend the
+  problematic commit and force push to the auto-generated branch.
+  Alternatively, you can create a new PR, which is noisier.
 
 ## Cherry-picks for unsupported releases
 
-The release team only supports & patches `n-3` releases (`n` being the latest release of Kubernetes). In January of 2019 the community discovered a regression, that was introduced in a post-release patch, but was currently no longer supported.
+The release team only supports & patches `n-3` releases (`n` being the latest
+release of Kubernetes). In January of 2019 the community discovered a
+regression, that was introduced in a post-release patch, but was currently no
+longer supported.
 
-As discussed in a sig-release meeting on 2019-01-15, a fix was backported to the non supported version.
+As discussed in a sig-release meeting on 2019-01-15, a fix was backported to
+the non supported version.
 
 Reference PR: [#72860](https://github.com/kubernetes/kubernetes/pull/72860#issuecomment-454072746)
 
 The specific criteria driving the decision was:
 
 - CI was still available for the version
-- The regression was introduced as a patch (and not part of the official release)
+- The regression was introduced as a patch (and not part of the official
+  release)
 - The issue being fixed is of sufficient **[severity & impact](#what-kind-of-prs-are-good-for-cherry-picks)**
-- The fix is well understood and contained (doesn’t introduce risk of additional regressions)
+- The fix is well understood and contained (doesn’t introduce risk of
+  additional regressions)
 
 A note about the specific case in [#72860](https://github.com/kubernetes/kubernetes/pull/72860#issuecomment-454072746):
 
 - The patch was exceedingly tiny and very unlikely to introduce new problems
-- Luckily, it was caught shortly after the release was supposed to be unsupported
\ No newline at end of file
+- Luckily, it was caught shortly after the release was supposed to be
+  unsupported
diff --git a/contributors/devel/sig-release/getting-builds.md b/contributors/devel/sig-release/getting-builds.md
index 50ae98f0..cbfbbf6e 100644
--- a/contributors/devel/sig-release/getting-builds.md
+++ b/contributors/devel/sig-release/getting-builds.md
@@ -32,9 +32,9 @@ You can also use the gsutil tool to explore the Google Cloud Storage release
 buckets. Here are some examples:
 
 ```sh
-gsutil cat gs://kubernetes-release-dev/ci/latest.txt          # output the latest ci version number
-gsutil ls gs://kubernetes-release-dev/ci/v0.20.0-29-g29a55cc/ # list the contents of a ci release
-gsutil ls gs://kubernetes-release/release                 # list all official releases and rcs
+gsutil cat gs://kubernetes-release-dev/ci/latest.txt           # output the latest ci version number
+gsutil ls gs://kubernetes-release-dev/ci/v0.20.0-29-g29a55cc/  # list the contents of a ci release
+gsutil ls gs://kubernetes-release/release                      # list all official releases and rcs
 ```
 
 ## Install `gsutil`
@@ -42,6 +42,6 @@ gsutil ls gs://kubernetes-release/release                 # list all official re
 Example installation:
 
 ```console
-$ curl -sSL https://storage.googleapis.com/pub/gsutil.tar.gz | sudo tar -xz -C /usr/local/src
-$ sudo ln -s /usr/local/src/gsutil/gsutil /usr/bin/gsutil
+curl -sSL https://storage.googleapis.com/pub/gsutil.tar.gz | sudo tar -xz -C /usr/local/src
+sudo ln -s /usr/local/src/gsutil/gsutil /usr/bin/gsutil
 ```
diff --git a/contributors/devel/sig-release/release.md b/contributors/devel/sig-release/release.md
index ae9de784..bb8288ee 100644
--- a/contributors/devel/sig-release/release.md
+++ b/contributors/devel/sig-release/release.md
@@ -4,116 +4,109 @@ This document is focused on Kubernetes developers and contributors
 who need to create a feature, issue, or pull request which targets a specific
 release milestone.
 
--   [TL;DR](#tldr)
--   [Definitions](#definitions)
--   [The Release Cycle](#the-release-cycle)
--   [Removal Of Items From The Milestone](#removal-of-items-from-the-milestone)
--   [Adding An Item To The Milestone](#adding-an-item-to-the-milestone)
-    -   [Milestone Maintainers](#milestone-maintainers)
-    -   [Feature additions](#feature-additions)
-    -   [Issue additions](#issue-additions)
-    -   [PR Additions](#pr-additions)
--   [Other Required Labels](#other-required-labels)
-    -   [SIG Owner Label](#sig-owner-label)
-    -   [Priority Label](#priority-label)
-    -   [Issue Kind Label](#issue-kind-label)
+- [TL;DR](#tldr)
+  - [Normal Dev (Weeks 1-8)](#normal-dev-weeks-1-8)
+  - [Code Freeze (Weeks 9-11)](#code-freeze-weeks-9-11)
+  - [Post-Release (Weeks 11+)](#post-release-weeks-11)
+- [Definitions](#definitions)
+- [The Release Cycle](#the-release-cycle)
+- [Removal Of Items From The Milestone](#removal-of-items-from-the-milestone)
+- [Adding An Item To The Milestone](#adding-an-item-to-the-milestone)
+  - [Milestone Maintainers](#milestone-maintainers)
+  - [Feature additions](#feature-additions)
+  - [Issue additions](#issue-additions)
+  - [PR Additions](#pr-additions)
+- [Other Required Labels](#other-required-labels)
+  - [SIG Owner Label](#sig-owner-label)
+  - [Priority Label](#priority-label)
+  - [Issue/PR Kind Label](#issuepr-kind-label)
 
 The process for shepherding features, issues, and pull requests
 into a Kubernetes release spans multiple stakeholders:
-* the feature, issue, or pull request owner
-* SIG leadership
-* the release team
+
+- the feature, issue, or pull request owner
+- SIG leadership
+- the release team
 
 Information on workflows and interactions are described below.
 
 As the owner of a feature, issue, or pull request (PR), it is your
-responsibility to ensure release milestone requirements are met.
-Automation and the release team will be in contact with you if
-updates are required, but inaction can result in your work being
-removed from the milestone.  Additional requirements exist when the
-target milestone is a prior release (see [cherry pick
-process](cherry-picks.md) for more information).
+responsibility to ensure release milestone requirements are met. Automation and
+the release team will be in contact with you if updates are required, but
+inaction can result in your work being removed from the milestone.  Additional
+requirements exist when the target milestone is a prior release (see
+[cherry pick process](cherry-picks.md) for more information).
 
 ## TL;DR
 
-If you want your PR to get merged, it needs the following required labels and milestones, represented here by the Prow /commands it would take to add them:
-<table>
-<tr>
-<td></td>
-<td>Normal Dev</td>
-<td>Code Freeze</td>
-<td>Post-Release</td>
-</tr>
-<tr>
-<td></td>
-<td>Weeks 1-8</td>
-<td>Weeks 9-11</td>
-<td>Weeks 11+</td>
-</tr>
-<tr>
-<td>Required Labels</td>
-<td>
-<ul>
-<!--Weeks 1-8-->
-<li>/sig {name}</li>
-<li>/kind {type}</li>
-<li>/lgtm</li>
-<li>/approved</li>
-</ul>
-</td>
-<td>
-<ul>
-<!--Weeks 9-11-->
-<li>/milestone {v1.y}</li>
-<li>/sig {name}</li>
-<li>/kind {bug, failing-test}</li>
-<li>/lgtm</li>
-<li>/approved</li>
-</ul>
-</td>
-<td>
-<!--Weeks 11+-->
+If you want your PR to get merged, it needs the following required labels and
+milestones, represented here by the Prow /commands it would take to add them:
+
+### Normal Dev (Weeks 1-8)
+
+- /sig {name}
+- /kind {type}
+- /lgtm
+- /approved
+
+### Code Freeze (Weeks 9-11)
+
+- /milestone {v1.y}
+- /sig {name}
+- /kind {bug, failing-test}
+- /lgtm
+- /approved
+
+### Post-Release (Weeks 11+)
+
 Return to 'Normal Dev' phase requirements:
-<ul>
-<li>/sig {name}</li>
-<li>/kind {type}</li>
-<li>/lgtm</li>
-<li>/approved</li>
-</ul>
-
-Merges into the 1.y branch are now [via cherrypicks](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md), approved by release branch manager.
-</td>
-<td>
-<ul>
-</td>
-</tr>
-</table>
-
-In the past there was a requirement for a milestone targeted pull
-request to have an associated GitHub issue opened, but this is no
-longer the case.  Features are effectively GitHub issues or
-[KEPs](https://git.k8s.io/community/keps)
-which lead to subsequent PRs. The general labeling process should
-be consistent across artifact types.
+
+- /sig {name}
+- /kind {type}
+- /lgtm
+- /approved
+
+Merges into the 1.y branch are now [via cherrypicks](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md),
+approved by release branch manager.
+
+In the past there was a requirement for a milestone targeted pull request to
+have an associated GitHub issue opened, but this is no longer the case.
+Features are effectively GitHub issues or [KEPs](https://git.k8s.io/community/keps)
+which lead to subsequent PRs. The general labeling process should be consistent
+across artifact types.
 
 ---
 
 ## Definitions
 
-- *issue owners*: Creator, assignees, and user who moved the issue into a release milestone.
+- *issue owners*: Creator, assignees, and user who moved the issue into a
+  release milestone
 - *release team*: Each Kubernetes release has a team doing project
-  management tasks described
-  [here](https://git.k8s.io/sig-release/release-team/README.md).  The
-  contact info for the team associated with any given release can be
-  found [here](https://git.k8s.io/sig-release/releases/).
-- *Y days*: Refers to business days (using the location local to the release-manager M-F).
+  management tasks described [here](https://git.k8s.io/sig-release/release-team/README.md).
+  The contact info for the team associated with any given release can be found
+  [here](https://git.k8s.io/sig-release/releases/).
+- *Y days*: Refers to business days (using the location local to the release
+  manager M-F).
 - *enhancement*: see "[Is My Thing an Enhancement?](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)
-- *[Enhancement Freeze](https://git.k8s.io/sig-release/releases/release_phases.md#enhancements-freeze)*: Usually during Week 4 of a release cycle: the deadline by which KEPs have to be completed in order for enhancements to be part of the current release
-- *[Exception Request](https://git.k8s.io/sig-release/releases/release_phases.md#exceptions)*: The process of requesting an extension on the deadline for a particular Enhancement
-- *[Code Freeze](https://git.k8s.io/sig-release/releases/release_phases.md#code-freeze)*: The period of ~4 weeks before the final release date, during which only critical bug fixes are merged into the release.
-- *[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)*: The process of removing an Enhancement from a release milestone if it is not fully implemented or is otherwise considered not stable.
-- *release milestone*: semantic version string or [GitHub milestone](https://help.github.com/articles/associating-milestones-with-issues-and-pull-requests/) referring to a release MAJOR.MINOR vX.Y version.  See also [release versioning](http://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
-- *release branch*: Git branch "release-X.Y" created for the vX.Y milestone.  Created at the time of the vX.Y-beta.0 release and maintained after the release for approximately 9 months with vX.Y.Z patch releases.
+- *[Enhancement Freeze](https://git.k8s.io/sig-release/releases/release_phases.md#enhancements-freeze)*:
+  the deadline by which KEPs have to be completed in order for enhancements to
+  be part of the current release
+- *[Exception Request](https://git.k8s.io/sig-release/releases/release_phases.md#exceptions)*:
+  The process of requesting an extension on the deadline for a particular
+  Enhancement
+- *[Code Freeze](https://git.k8s.io/sig-release/releases/release_phases.md#code-freeze)*:
+  The period of ~4 weeks before the final release date, during which only
+  critical bug fixes are merged into the release.
+- *[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)*:
+  The process of removing an Enhancement from a release milestone if it is not
+  fully implemented or is otherwise considered not stable.
+- *release milestone*: semantic version string or
+  [GitHub milestone](https://help.github.com/articles/associating-milestones-with-issues-and-pull-requests/)
+  referring to a release MAJOR.MINOR vX.Y version. See also
+  [release versioning](http://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
+- *release branch*: Git branch "release-X.Y" created for the vX.Y milestone.
+  Created at the time of the vX.Y-beta.0 release and maintained after the
+  release for approximately 9 months with vX.Y.Z patch releases.
 
 ## The Release Cycle
 
@@ -121,138 +114,134 @@ be consistent across artifact types.
 
 Kubernetes releases currently happen four times per year.  The release
 process can be thought of as having three main phases:
-* Feature Definition
-* Implementation
-* Stabilization
-
-But in reality this is an open source and agile project, with feature
-planning and implementation happening at all times.  Given the
-project scale and globally distributed developer base, it is critical
-to project velocity to not rely on a trailing stabilization phase and
-rather have continuous integration testing which ensures the
-project is always stable so that individual commits can be
+
+- Feature Definition
+- Implementation
+- Stabilization
+
+But in reality this is an open source and agile project, with feature planning
+and implementation happening at all times. Given the project scale and globally
+distributed developer base, it is critical to project velocity to not rely on a
+trailing stabilization phase and rather have continuous integration testing
+which ensures the project is always stable so that individual commits can be
 flagged as having broken something.
 
-With ongoing feature definition through the year, some set of items
-will bubble up as targeting a given release.  The **enhancement freeze**
-starts ~4 weeks into release cycle.  By this point all intended
-feature work for the given release has been defined in suitable
-planning artifacts in conjunction with the Release Team's [enhancements
-lead](https://git.k8s.io/sig-release/release-team/role-handbooks/enhancements/README.md).
+With ongoing feature definition through the year, some set of items will bubble
+up as targeting a given release. The **enhancement freeze** starts ~4 weeks
+into release cycle. By this point all intended feature work for the given
+release has been defined in suitable planning artifacts in conjunction with the
+Release Team's [enhancements lead](https://git.k8s.io/sig-release/release-team/role-handbooks/enhancements/README.md).
 
-After enhancement freeze, tracking milestones on PRs and Issues is
-important. Items within the milestone are used as a punchdown list to
-complete the release. *On issues*, milestones must be applied correctly, via
-triage by the SIG, so that release team can track bugs and enhancements (any
-enhancement related issue needs a milestone)
+After enhancement freeze, tracking milestones on PRs and Issues is important.
+Items within the milestone are used as a punchdown list to complete the
+release. *On issues*, milestones must be applied correctly, via triage by the
+SIG, so that release team can track bugs and enhancements (any
+enhancement-related issue needs a milestone).
 
 There is some automation in place to help automatically-assign milestones to
 PRs. This automation only applies to the following repos:
 
-* kubernetes/enhancements
-* kubernetes/kubernetes
-* kubernetes/release
-* kubernetes/sig-release
-* kubernetes/test-infra
-
-At creation time, PRs against the master branch need humans to hint at which milestone
-they might want the PR to target. Once merged, PRs against the master branch have
-milestones auto-applied so from that time onward human management of that PR's
-milestone is less necessary. On PRs against anything not the master branch, milestones
-are auto-applied when the PR is created so no human management of the milestone
-is ever necessary.
+- kubernetes/enhancements
+- kubernetes/kubernetes
+- kubernetes/release
+- kubernetes/sig-release
+- kubernetes/test-infra
 
+At creation time, PRs against the master branch need humans to hint at which
+milestone they might want the PR to target. Once merged, PRs against the master
+branch have milestones auto-applied so from that time onward human management
+of that PR's milestone is less necessary. On PRs against anything not the
+master branch, milestones are auto-applied when the PR is created so no human
+management of the milestone is ever necessary.
 
-Any other effort that
-should be tracked by the release team that doesn't fall under that
-automation umbrella should be have a milestone applied.
+Any other effort that should be tracked by the release team that doesn't fall
+under that automation umbrella should be have a milestone applied.
 
-*"Milestone early and milestone often. Everyone will be happier."*
+Implementation and bug fixing is ongoing across the cycle, but culminates in a
+code freeze period:
 
-Implementation and bugfixing is ongoing across the cycle, but
-culminates in a code freeze period:
-* The **code freeze** starts in week ~10 and continues for ~2 weeks.
+- The **code freeze*- starts in week ~10 and continues for ~2 weeks.
   Only critical bug fixes are accepted into the release codebase.
 
-There are approximately two weeks following code freeze, and preceding
-release, during which all remaining critical issues must be resolved
-before release.  This also gives time for documentation finalization.
+There are approximately two weeks following code freeze, and preceding release,
+during which all remaining critical issues must be resolved before release.
+This also gives time for documentation finalization.
 
-When the code base is sufficiently stable, the master branch re-opens
-for general development and work begins there for the next release
-milestone. Any remaining modifications for the current release are cherry
-picked from master back to the release branch.  The release is built from
-the release branch.
+When the code base is sufficiently stable, the master branch re-opens for
+general development and work begins there for the next release milestone. Any
+remaining modifications for the current release are cherry picked from master
+back to the release branch. The release is built from the release branch.
 
-Following release, the [Release Branch
-Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager/README.md)
-cherry picks additional critical fixes from the master branch for
-a period of around 9 months, leaving an overlap of three release
-versions forward support.  Thus, each release is part of a broader
-Kubernetes lifecycle:
+Following release, the [Release Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager/README.md)
+cherry picks additional critical fixes from the master branch for a period of
+around 9 months, leaving an overlap of three release versions forward support.
+Thus, each release is part of a broader Kubernetes lifecycle:
 
 ![Image of Kubernetes release lifecycle spanning three releases](release-lifecycle.png)
 
 ## Removal Of Items From The Milestone
 
-Before getting too far into the process for adding an item to the
-milestone, please note:
+Before getting too far into the process for adding an item to the milestone,
+please note:
 
-Members of the Release Team may remove Issues from the milestone
-if they or the responsible SIG determine that the issue is not
-actually blocking the release and is unlikely to be resolved in a
-timely fashion.
+Members of the Release Team may remove Issues from the milestone if they or the
+responsible SIG determine that the issue is not actually blocking the release
+and is unlikely to be resolved in a timely fashion.
 
-Members of the Release Team may remove PRs from the milestone for
-any of the following, or similar, reasons:
+Members of the Release Team may remove PRs from the milestone for any of the
+following, or similar, reasons:
 
-* PR is potentially de-stabilizing and is not needed to resolve a blocking issue;
-* PR is a new, late feature PR and has not gone through the features process or the exception process;
-* There is no responsible SIG willing to take ownership of the PR and resolve any follow-up issues with it;
-* PR is not correctly labelled;
-* Work has visibly halted on the PR and delivery dates are uncertain or late.
+- PR is potentially de-stabilizing and is not needed to resolve a blocking
+  issue
+- PR is a new, late feature PR and has not gone through the features process or
+  the exception process
+- There is no responsible SIG willing to take ownership of the PR and resolve
+  any follow-up issues with it
+- PR is not correctly labelled
+- Work has visibly halted on the PR and delivery dates are uncertain or late
 
-While members of the Release Team will help with labelling and
-contacting SIG(s), it is the responsibility of the submitter to
-categorize PRs, and to secure support from the relevant SIG to
-guarantee that any breakage caused by the PR will be rapidly resolved.
+While members of the Release Team will help with labelling and contacting
+SIG(s), it is the responsibility of the submitter to categorize PRs, and to
+secure support from the relevant SIG to guarantee that any breakage caused by
+the PR will be rapidly resolved.
 
-Where additional action is required, an attempt at human to human
-escalation will be made by the release team through the following
-channels:
+Where additional action is required, an attempt at human to human escalation
+will be made by the release team through the following channels:
 
-- Comment in GitHub mentioning the SIG team and SIG members as appropriate for the issue type
+- Comment in GitHub mentioning the SIG team and SIG members as appropriate for
+  the issue type
 - Emailing the SIG mailing list
-  - bootstrapped with group email addresses from the [community sig list](/sig-list.md)
+  - bootstrapped with group email addresses from the
+    [community sig list](/sig-list.md)
   - optionally also directly addressing SIG leadership or other SIG members
 - Messaging the SIG's Slack channel
-  - bootstrapped with the slackchannel and SIG leadership from the [community sig list](/sig-list.md)
+  - bootstrapped with the slackchannel and SIG leadership from the
+    [community sig list](/sig-list.md)
   - optionally directly "@" mentioning SIG leadership or others by handle
 
 ## Adding An Item To The Milestone
 
 ### Milestone Maintainers
 
-The members of the GitHub [“kubernetes-milestone-maintainers”
-team](https://github.com/orgs/kubernetes/teams/kubernetes-milestone-maintainers/members)
+The members of the GitHub
+[“kubernetes-milestone-maintainers” team](https://github.com/orgs/kubernetes/teams/kubernetes-milestone-maintainers/members)
 are entrusted with the responsibility of specifying the release milestone on
-GitHub artifacts.  This group is [maintained by
-SIG-Release](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers)
+GitHub artifacts. This group is [maintained by
+SIG Release](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers)
 and has representation from the various SIGs' leadership.
 
 ### Feature additions
 
-Feature planning and definition takes many forms today, but a typical
-example might be a large piece of work described in a
-[KEP](https://git.k8s.io/community/keps), with associated
-task issues in GitHub.  When the plan has reached an implementable state and
-work is underway, the feature or parts thereof are targeted for an upcoming
-milestone by creating GitHub issues and marking them with the Prow "/milestone"
-command.
+Feature planning and definition takes many forms today, but a typical example
+might be a large piece of work described in a
+[KEP](https://git.k8s.io/community/keps), with associated task issues in
+GitHub. When the plan has reached an implementable state and work is underway,
+the feature or parts thereof are targeted for an upcoming milestone by creating
+GitHub issues and marking them with the Prow "/milestone" command.
 
-For the first ~4 weeks into the release cycle, the release team's
-Enhancements Lead will interact with SIGs and feature owners via GitHub,
-Slack, and SIG meetings to capture all required planning artifacts.
+For the first ~4 weeks into the release cycle, the release team's Enhancements
+Lead will interact with SIGs and feature owners via GitHub, Slack, and SIG
+meetings to capture all required planning artifacts.
 
 If you have a feature to target for an upcoming release milestone, begin a
 conversation with your SIG leadership and with that release's Enhancements
@@ -260,73 +249,74 @@ Lead.
 
 ### Issue additions
 
-Issues are marked as targeting a milestone via the Prow
-"/milestone" command.
+Issues are marked as targeting a milestone via the Prow "/milestone" command.
 
-The release team's [Bug Triage
-Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/bug-triage/README.md) and overall community watch
-incoming issues and triage them, as described in the contributor
-guide section on [issue triage](/contributors/guide/issue-triage.md).
+The release team's [Bug Triage Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/bug-triage/README.md)
+and overall community watch incoming issues and triage them, as described in
+the contributor guide section on
+[issue triage](/contributors/guide/issue-triage.md).
 
-Marking issues with the milestone provides the community better
-visibility regarding when an issue was observed and by when the community
-feels it must be resolved.  During code freeze, to merge a PR it is required
-that a release milestone is set.
+Marking issues with the milestone provides the community better visibility
+regarding when an issue was observed and by when the community feels it must be
+resolved.  During code freeze, to merge a PR it is required that a release
+milestone is set.
 
-An open issue is no longer required for a PR, but open issues and
-associated PRs should have synchronized labels.  For example a high
-priority bug issue might not have its associated PR merged if the PR is
-only marked as lower priority.
+An open issue is no longer required for a PR, but open issues and associated
+PRs should have synchronized labels. For example a high priority bug issue
+might not have its associated PR merged if the PR is only marked as lower
+priority.
 
 ### PR Additions
 
-PRs are marked as targeting a milestone via the Prow
-"/milestone" command.
+PRs are marked as targeting a milestone via the Prow "/milestone" command.
 
 This is a blocking requirement during code freeze as described above.
 
 ## Other Required Labels
 
-*Note* [Here is the list of labels and their use and purpose.](https://git.k8s.io/test-infra/label_sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs)
+[Here is the list of labels and their use and purpose.](https://git.k8s.io/test-infra/label_sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs)
 
 ### SIG Owner Label
 
-The SIG owner label defines the SIG to which we escalate if a
-milestone issue is languishing or needs additional attention.  If
-there are no updates after escalation, the issue may be automatically
-removed from the milestone.
+The SIG owner label defines the SIG to which we escalate if a milestone issue
+is languishing or needs additional attention. If there are no updates after
+escalation, the issue may be automatically removed from the milestone.
 
-These are added with the Prow "/sig" command. For example to add
-the label indicating SIG Storage is responsible, comment with `/sig
-storage`.
+These are added with the Prow "/sig" command. For example to add the label
+indicating SIG Storage is responsible, comment with `/sig storage`.
 
 ### Priority Label
 
-Priority labels are used to determine an escalation path before
-moving issues out of the release milestone.  They are also used to
-determine whether or not a release should be blocked on the resolution
-of the issue.
+Priority labels are used to determine an escalation path before moving issues
+out of the release milestone. They are also used to determine whether or not a
+release should be blocked on the resolution of the issue.
 
-- `priority/critical-urgent`: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels.
+- `priority/critical-urgent`: Never automatically move out of a release
+  milestone; continually escalate to contributor and SIG through all available
+  channels.
   - considered a release blocking issue
   - code freeze: issue owner update frequency: daily
-  - would require a patch release if left undiscovered until after the minor release.
-- `priority/important-soon`: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.
+  - would require a patch release if left undiscovered until after the minor
+    release
+- `priority/important-soon`: Escalate to the issue owners and SIG owner; move
+  out of milestone after several unsuccessful escalation attempts.
   - not considered a release blocking issue
   - would not require a patch release
-  - will automatically be moved out of the release milestone at code freeze after a 4 day grace period
-- `priority/important-longterm`: Escalate to the issue owners; move out of the milestone after 1 attempt.
+  - will automatically be moved out of the release milestone at code freeze
+    after a 4 day grace period
+- `priority/important-longterm`: Escalate to the issue owners; move out of the
+  milestone after 1 attempt.
   - even less urgent / critical than `priority/important-soon`
   - moved out of milestone more aggressively than `priority/important-soon`
 
 ### Issue/PR Kind Label
 
-The issue kind is used to help identify the types of changes going
-into the release over time.  This may allow the release team to
-develop a better understanding of what sorts of issues we would
-miss with a faster release cadence.
+The issue kind is used to help identify the types of changes going into the
+release over time. This may allow the release team to develop a better
+understanding of what sorts of issues we would miss with a faster release
+cadence.
 
-For release targeted issues, including pull requests, one of the following 
+For release targeted issues, including pull requests, one of the following
 issue kind labels must be set:
 
 - `kind/api-change`: Adds, removes, or changes an API