fix: syntax errors in the document

docs/Backwards_Compatibility.md

@@ -102,7 +102,7 @@ is that unlike enums, which have a bounded set of allowed values, the set of
 valid enforcement actions is unbounded. This makes it more akin to a
 [union set](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#unions).
 
-Currently Gatekeeper is deviating slightly from the `enforcementAction` spec by
+Current Gatekeeper is deviating slightly from the `enforcementAction` spec by
 defaulting to rejecting constraints with an unknown enforcement action (this
 behavior can be disabled via the `--disable-enforcementaction-validation` flag).
 This should be a non-issue as a missing constraint and an ignored constraint are

docs/RELEASE.md

@@ -15,24 +15,24 @@ Building involves obtaining a copy of the repository and triggering a build as p
 
 Publishing involves creating a release tag and creating a new *Release* on GitHub.
 
-## Cherry picking
+## Cherry-picking
 
-There is an optional script for cherry picking PRs that should make the process easier.
+There is an optional script for cherry-picking PRs that should make the process easier.
 
 Prerequisites:
 - `hub` binary is installed. If not, `hub` can be installed by `go get github.com/github/hub`.
-- Set GitHub user name with `export GITHUB_USER=<your GitHub username>`
+- Set GitHub username with `export GITHUB_USER=<your GitHub username>`
 - Set fork remote with `export FORK_REMOTE=<your fork remote name, by default it is "origin">`
 - Set upstream remote with `export UPSTREAM_REMOTE=<upstream remote name, by default it is "upstream">`
 
 Usage: `./third_party/k8s.io/kubernetes/hack/cherry_pick_pull.sh upstream/release-3.1 123`
-For example, this will cherry pick PR #123 into `upstream/release-3.1` branch and will create a PR for you.
+For example, this will cherry-pick PR #123 into `upstream/release-3.1` branch and will create a PR for you.
 
 You can also combine multiple PRs by separating them with spaces (`./third_party/k8s.io/kubernetes/hack/cherry_pick_pull.sh upstream/release-3.1 123 456`)
 
 If you want to run the script with dry run mode, set `DRY_RUN` to `true`.
 
-Cherry pick script is copied over from https://github.com/kubernetes/kubernetes/blob/master/hack/cherry_pick_pull.sh. For more information, see https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md
+Cherry-pick script is copied over from https://github.com/kubernetes/kubernetes/blob/master/hack/cherry_pick_pull.sh. For more information, see https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md
 
 ## Release Cadence
 
@@ -48,7 +48,7 @@ Once we are ready to release the new minor version, we will create a release bra
 
 Once we are confident in our latest release candidate, we will tag the release branch with a stable release (`vX.Y+1.0`), and the development cycle will start all over again. We recommend using stable releases of Gatekeeper in a production environment. We also encourage users to upgrade to the latest stable patch releases (`vX.Y+1.Z`) for bug fixes, security fixes, and performance improvements.
 
-For patch releases (e.g. `vX.Y.1`), refer to the [cherry picking](#cherry-picking) section on how to cherry-pick merged pull requests to an existing release branch.
+For patch releases (e.g. `vX.Y.1`), refer to the [cherry-picking](#cherry-picking) section on how to cherry-pick merged pull requests to an existing release branch.
 
 ## Release Pull Requests
 

docs/Release_Management.md

@@ -7,8 +7,8 @@ This document describes Gatekeeper project release management, which includes re
 ## Legend
 
 - **X.Y.Z** refers to the version (git tag) of Gatekeeper that is released. This is the version of the Gatekeeper image and the Chart version.
-- **Breaking changes** refer to schema changes, flag changes, and behavior changes of Gatekeeper that may require a clean install during upgrade and it may introduce changes that could break backward compatibility.
-- **Milestone** should be designed to include feature sets to accommodate 2 months release cycles including test gates. GitHub milestones are used by maintainers to manage each release. PRs and Issues for each release should be created as part of a corresponding milestone.
+- **Breaking changes** refer to schema changes, flag changes, and behavior changes of Gatekeeper that may require a clean installation during upgrade, and it may introduce changes that could break backward compatibility.
+- **Milestone** should be designed to include feature sets to accommodate 2 months release cycles including test gates. GitHub's milestones are used by maintainers to manage each release. PRs and Issues for each release should be created as part of a corresponding milestone.
 - **Patch releases** refer to applicable fixes, including security fixes, may be backported to support releases, depending on severity and feasibility.
 - **Test gates** should include soak tests and upgrade tests from the last minor version.
 
@@ -52,7 +52,7 @@ Applicable fixes, including security fixes, may be cherry-picked into the releas
 
 We expect users to stay reasonably up-to-date with the versions of Gatekeeper they use in production, but understand that it may take time to upgrade. We expect users to be running approximately the latest patch release of a given minor release and encourage users to upgrade as soon as possible.
 
-We expect to "support" n (current) and n-1 major.minor releases. "Support" means we expect users to be running that version in production. For example, when v3.3.0 comes out, v3.1.x will no longer be supported for patches and we encourage users to upgrade to a supported version as soon as possible.
+We expect to "support" n (current) and n-1 major.minor releases. "Support" means we expect users to be running that version in production. For example, when v3.3.0 comes out, v3.1.x will no longer be supported for patches, and we encourage users to upgrade to a supported version as soon as possible.
 
 ## Supported Kubernetes Versions