optimize partial descriptions in the document

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

CONTRIBUTING.md

@@ -51,7 +51,7 @@ If you're new to the project and want to help, but don't know where to start, we
 should not need deep knowledge of the system. [Have a look and see if anything sounds
 interesting](https://github.com/kubernetes-sigs/cluster-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22).
 Before starting to work on the issue, make sure that it doesn't have a [lifecycle/active](https://github.com/kubernetes-sigs/cluster-api/labels/lifecycle%2Factive) label. If the issue has been assigned, reach out to the assignee.
-Alternatively, read some of the docs on other controllers and try to write your own, file and fix any/all issues that
+Alternatively, read some docs on other controllers and try to write your own, file and fix any/all issues that
 come up, including gaps in documentation!
 
 If you're a more experienced contributor, looking at unassigned issues in the next release milestone is a good way to find work that has been prioritized. For example, if the latest minor release is `v1.0`, the next release milestone is `v1.1`.
@@ -198,7 +198,7 @@ containing markdown files and we use [mdBook][] to build it into a static
 website.
 
 After making changes locally you can run `make serve-book` which will build the HTML version
-and start a web server so you can preview if the changes render correctly at
+and start a web server, so you can preview if the changes render correctly at
 http://localhost:3000; the preview auto-updates when changes are detected.
 
 Note: you don't need to have [mdBook][] installed, `make serve-book` will ensure
@@ -287,7 +287,7 @@ Code reviews should generally look at:
 - **Complexity**: Could the code be made simpler?  Would another developer be able to easily understand and use this code when they come across it in the future?
 - **Tests**: Does the code have correct and well-designed tests?
 - **Naming**: Did the developer choose clear names for variable, types, methods, functions, etc.?
-- **Comments**: Are the comments clear and useful? Do they explain the why rather than what?
+- **Comments**: Are the comments clear and useful? Do they explain why rather than what?
 - **Documentation**: Did the developer also update relevant documentation?
 
 See [Code Review in Cluster API](REVIEWING.md) for a more focused list of review items.
@@ -321,7 +321,7 @@ For big feature, API and contract amendments, we follow the CAEP process as outl
 Proof of concepts, code experiments, or other initiatives can live under the `exp` folder or behind a feature gate.
 
 - Experiments SHOULD not modify any of the publicly exposed APIs (e.g. CRDs).
-- Experiments SHOULD not modify any existing CRD types outside of the experimental API group(s).
+- Experiments SHOULD not modify any existing CRD types outside the experimental API group(s).
 - Experiments SHOULD not modify any existing command line contracts.
 - Experiments MUST not cause any breaking changes to existing (non-experimental) Go APIs.
 - Experiments SHOULD introduce utility helpers in the go APIs for experiments that cross multiple components
@@ -349,7 +349,7 @@ Proof of concepts, code experiments, or other initiatives can live under the `ex
 - Experiment Graduation checklist:
   - [ ] MAY provide a way to be disabled, any feature gates MUST be marked as 'GA'
   - [ ] MUST undergo a full Kubernetes-style API review and update the CAEP with the plan to address any issues raised
-  - [ ] CAEP MUST be in an implementable state and is fully up to date with the current implementation
+  - [ ] CAEP MUST be in an implementable state and is fully up-to-date with the current implementation
   - [ ] CAEP MUST define transition plan for moving out of the experimental api group and code directories
   - [ ] CAEP MUST define any upgrade steps required for Existing Management and Workload Clusters
   - [ ] CAEP MUST define any upgrade steps required to be implemented by out-of-tree bootstrap, control plane, and infrastructure providers.
@@ -363,7 +363,7 @@ There may be times, however, when `main` is closed for breaking changes. This is
 release of a new minor version.
 
 Breaking changes are not allowed in release branches, as these represent minor versions that have already been released.
-These versions have consumers who expect the APIs, behaviors, etc. to remain stable during the life time of the patch
+These versions have consumers who expect the APIs, behaviors, etc. to remain stable during the lifetime of the patch
 stream for the minor release.
 
 Examples of breaking changes include:
@@ -475,7 +475,7 @@ organization and can request membership by [opening an
 issue](https://github.com/kubernetes/org/issues/new?template=membership.md&title=REQUEST%3A%20New%20membership%20for%20%3Cyour-GH-handle%3E)
 against the kubernetes/org repo.
 
-However, if you are a member of any of the related Kubernetes GitHub organizations but not of the Kubernetes org, you
+However, if you are a member of the related Kubernetes GitHub organizations but not of the Kubernetes org, you
 will need explicit sponsorship for your membership request. You can read more about Kubernetes membership and
 sponsorship [here](https://git.k8s.io/community/community-membership.md).
 

README.md

@@ -18,7 +18,7 @@
 
 ## ✨ What is the Cluster API?
 
-Cluster API is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters.
+Cluster API is a Kubernetes subproject focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters.
 
 Started by the Kubernetes Special Interest Group (SIG) Cluster Lifecycle, the Cluster API project uses Kubernetes-style APIs and patterns to automate cluster lifecycle management for platform operators. The supporting infrastructure, like virtual machines, networks, load balancers, and VPCs, as well as the Kubernetes cluster configuration are all defined in the same way that application developers operate deploying and managing their workloads. This enables consistent and repeatable cluster deployments across a wide variety of infrastructure environments.
 

REVIEWING.md

@@ -25,7 +25,7 @@ feedback and suggestions.
 ## Resources
 
 - [Writing inclusive documentation](https://developers.google.com/style/inclusive-documentation)
-- [Contributor Summit NA 2019: Keeping the Bar High - How to be a bad ass Code Reviewer](https://www.youtube.com/watch?v=OZVv7-o8i40)
+- [Contributor Summit NA 2019: Keeping the Bar High - How to be a bad-ass Code Reviewer](https://www.youtube.com/watch?v=OZVv7-o8i40)
 - [Code Review Developer Guide - Google](https://google.github.io/eng-practices/review/)
 - [The Gentle Art Of Patch Review](https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/)
 
@@ -128,7 +128,7 @@ to help troubleshooting issues.
 
 ### Testing
 
-Testing plays an crucial role in ensuring the long term maintainability of the project.
+Testing plays a crucial role in ensuring the long term maintainability of the project.
 
 In Cluster API we are committed to have a good test coverage and also to have a nice and consistent style in implementing
 tests. For more information see [testing Cluster API](https://cluster-api.sigs.k8s.io/developer/testing.html).