release: incorporating a few review comments

Signed-off-by: Fabian Deutsch <[email protected]>

docs/release-procedure.md

@@ -5,10 +5,10 @@ Refer to [release.md](release.md) in order to learn about the high-level release
 
 # Creating Releases
 
-The actual releases are all cut using the kubevirt release-tool. This tool
+The actual releases are all cut using the kubevirt release tool. This tool
 automates the entire process of creating branches, signing tags, generating
-prow configs, and more. All you need to do is gather a few credentials
-in order to use the tool.
+prow configs, and more. To use the release tool, you need to prepare your
+credentials.
 
 ## Release Tool Credentials
 
@@ -18,9 +18,11 @@ You must have 2 items before you can create a release.
 
 [Instructions for adding GPG key to your github account](https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account)
 
-After adding the GPG key to github, export both the key and passphrase to files.
-Be aware that this results in the key and passphrase being placed into a plain
-text file on your machine. Make sure you don't place this in shared storage.
+After adding the GPG key to Gitub, export both the key and the passphrase to 
+separate files.
+Be aware that this results in both the key and passphrase being placed into
+plain text files on your machine. Make sure you don't place this in shared
+storage.
 
 **Example of exporting key to file**
 
@@ -98,7 +100,7 @@ The release process is mostly automatic and consists of the following steps:
    and uncheck the "This is a pre-release" box. This will make the release
    official
 
-6. Sent a friendly announcement email to <[email protected]> using
+6. Send a friendly announcement email to <[email protected]> using
    the release notes already present on the release's description in github.
 
 ## Creating New Patch Releases
@@ -120,12 +122,12 @@ The release itself is only a git signed tag as it's used for minor releases as w
    and uncheck the "This is a pre-release" box. This will make the release
    official
 
-4. Sent a friendly announcement email to <[email protected]> using
+4. Send a friendly announcement email to <[email protected]> using
    the release notes already present on the release's description in github.
 
 # Merging to Release Branches
 
-For every release a branch will be created following the pattern `release-x.y`.
+For every release, a branch will be created following the pattern `release-x.y`.
 For now, community members can propose pull requests to be included into a
 stable branch.
 Those pull requests should be limited to bug fixes and must not be

docs/release.md

@@ -60,14 +60,14 @@ The primary reasons for defining compatible Kubernetes releases are:
 - CI resources are finite. And people to maintain it as well.
 - Limit the maintenance burden
 - Setting the right expectations with end-users
-- Define when a KubeVirt release is ending it's regular support
+- Define when a KubeVirt release is ending its regular support
 
 The Kubernetes release corresponding to a KubeVirt release is defined in the release metadata of a KubeVirt release maintained by [SIG Release](https://github.com/kubevirt/sig-release/).
 
 ## Platform Support Skew
 
-While there are good reasons for defining a target Kubernetes release there are usually also needs to support more than one Kubernetes version.
-While the KubeVirt Community can not provide this support, patches to support other releases will also not be rejected as long as they are provided in a reasonable manner (scope and time wise).
+Although we target a specific Kubernetes release, we recognize that there are reasons to support more than one Kubernetes version.
+While the KubeVirt Community can not provide this support, patches to support other releases will be considered as long as they are provided in a reasonable manner (scope and time wise).
 
 
 # Schedule
@@ -186,7 +186,7 @@ gitGraph
 Today a KubeVirt release consists of two phases:
 
 1. _Stabilization phase_ - The timeframe from the stable branch cut all the way towards - and ending with - a new KubeVirt release
-2. _Maintenance phase_ - The timeframe start with a new KubeVirt release and ending with the release#s End-Of-Life
+2. _Maintenance phase_ - The timeframe starts with a new KubeVirt release and ends with the release's [End-Of-Life](#end-of-life-eol)
 
 ## Stabilization phase
 
@@ -220,7 +220,7 @@ The introduction of a new provider has the following phases:
 4. Periodic and presubmit lanes get introduced for the sigs `compute`, `network`, `storage` and `operator`, where
    1. while the periodics deliver a signal for how KubeVirt and the provider are interacting, the presubmits initially are to be triggered manually, so that teams can work on fixing bugs in either the provider or the KubeVirt code
    2. at the point when the periodics look stable enough, the presubmits are turned on to run on every PR
-   3. if the signal is looking stable enough, they are made voting
+   3. if the signal is looking stable enough, they are made voting (will gate a PR)
 
 ### Holidays
 
@@ -254,10 +254,10 @@ During the maintenance phase contributors can backport fixes to a stable branch
 
 ### Patch releases
 
-During the maintenance phase KubeVirt will provide patch releases on a irregular basis. 
+During the maintenance phase, KubeVirt will provide patch releases on an irregular basis. 
 
 ### End-Of-Life (EOL)
 
-A KubeVirt release will reach it's end of life (EOL) once the Kubernetes support period ends.
+A KubeVirt release will reach its end of life (EOL) once the Kubernetes support period ends.
 
 The EOL of a KubeVirt release is currently not enforced. Fixes can be backported as long as maintainers are willing to approve them.