Optimize the document for readability

Signed-off-by: Fish-pro <[email protected]>

Author: Fish-pro

README.md

@@ -8,7 +8,7 @@ Please see the [Support](#support) section below.
 ## What is Kubeadm ?
 
 Kubeadm is a tool built to provide best-practice "fast paths" for creating Kubernetes clusters.
-It performs the actions necessary to get a minimum viable, secure cluster up and running in a user friendly way.
+It performs the actions necessary to get a minimum viable, secure cluster up and running in a user-friendly way.
 Kubeadm's scope is limited to the local node filesystem and the Kubernetes API, and it is intended to be a composable building block of higher level tools.
 
 

docs/managing-e2e-tests.md

@@ -11,7 +11,7 @@ Kubernetes uses applications such as the web-based [testgrid](https://k8s-testgr
 The following folder contains all the SIG Cluster Lifecycle (the SIG that maintains kubeadm) originated test jobs:
 [sig-cluster-lifecycle](https://git.k8s.io/test-infra/config/jobs/kubernetes/sig-cluster-lifecycle)
 
-Please note that this document will only cover details on the `kubeadm*.yaml` files and only on some of the parameters
+Please note that this document will only cover details on the `kubeadm*.yaml` files and only on some parameters
 these files contain.
 
 For example, let's have a look at this file:
@@ -87,7 +87,7 @@ Let's define the size of the Kubernetes support skew as `N`.
 For `N=3`, 3 releases will be in support.
 
 When a new release is about to happen, the kubeadm test workflows and jobs have
-two be updated two times:
+to be updated two times:
 1. When the new `release-x.yy` branch of `kubernetes/kubernetes` is created and the
   `release-x.yy-*` test-grid dashboards are created.
   - Edit `kinder/hack/update-workflows.sh`:

docs/release-cycle.md

@@ -1,6 +1,6 @@
 ### kubeadm's release cycle and quarterly agenda
 
-Kubernetes has a well defined release process that improves with every release.
+Kubernetes has a well-defined release process that improves with every release.
 These notes provide some inspiration for how the Kubernetes developing flow actually can look like.
 
 Most of these tips and tricks are general and not kubeadm specific.
@@ -17,10 +17,10 @@ That said, nothing here is set in stone. See this as inspiration :)
 #### First month of the quarter (coding)
 
 - Create a new housekeeping tracking issue similar to [this one](https://github.com/kubernetes/kubeadm/issues/180).
-- Remove e2e tests for k8s/kubeadm versions outside of the support skew.
+- Remove e2e tests for k8s/kubeadm versions outside the support skew.
 - Manage cherrypicks for the current stable branch
   - Make sure high-priority bug reports are triaged and fixed.
-  - Create bug fixes, ensure they're merged, and cherry pick them to the release branch.
+  - Create bug fixes, ensure they're merged, and cherry-pick them to the release branch.
   - Coordinate with the patch release team.
 - Plan/prioritize features, testing work and bugs
   - At the beginning of each cycle the kubeadm team has a planning session during the kubeadm office hours meeting.

docs/test-failures.md

@@ -28,7 +28,7 @@ ultimately responsible for keeping this in check. For this reason, contributors
 should be encouraged to work with and get the help of maintainers where
 necessary.
 
-## A ecosystem/upstream change happens that breaks current tests
+## An ecosystem/upstream change happens that breaks current tests
 
 If tests fail due to an upstream change to test-infra or a related ecosystem
 project, it is the responsibility of maintainers to correct and recalibrate

docs/testing-pre-releases.md

@@ -212,7 +212,7 @@ make release-images
 
 ## Creating the Kubernetes cluster with kubeadm
 
-The kubernetes web site contains reference documentation for [installing kubeadm](https://kubernetes.io/docs/setup/independent/install-kubeadm/)
+The kubernetes website contains reference documentation for [installing kubeadm](https://kubernetes.io/docs/setup/independent/install-kubeadm/)
 and for [creating a cluster using it](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/).
 
 According to selected versions to be installed (the version of .deb or .rpm packages, the version of the kubeadm binary to be used, the version number of the control plane components) following variants to the standard procedure should be applied:

docs/updating-command-reference.md

@@ -16,7 +16,7 @@ sending a PR for `kubernetes/kubernetes`.
 Some of them will be for the new command - `*newcommand*`.
 - In your local copy of `kubernetes/website` navigate to this folder:
 `./content/en/docs/reference/setup-tools/kubeadm/generated`
-- Copy the `*newcommand*` files from `kubernetes/docs/admin/` to the this folder.
+- Copy the `*newcommand*` files from `kubernetes/docs/admin/` to the folder.
 - Create a PR for `kubernetes/website` and add these files to your commit.
 - Depending on the parent command of `newcommand` (in this case `config`) import the generated
 sub-command in the parent command MD file like so: