Merge pull request #725 from rushyrush/main

doc fixes

Author: k8s-ci-robot

CONTRIBUTING.md

@@ -31,18 +31,18 @@ If you're new to the project and want to help, but don't know where to start, we
 
 1. If you haven't already done so, sign a Contributor License Agreement (see details above).
 2. Fork the desired repo, develop and test your code changes.
-3. Submit a pull request. 
+3. Submit a pull request.
     i. All code PR must be labeled with one of the following kinds
-	- `/kind feature` for PRs related to adding new features/tests 
-	- `/kind bug` for PRs releated to bug fixes and patches 
-	- `/kind api-change` for PRs releated to adding, removing, or otherwise changing an API 
-	- `/kind cleanup` for PRs releated to code refactoring and cleanup 
-	- `/kind deprecation` for PRs related to a feature/enhancement marked for deprecation 
-	- `/kind design` for PRs releated to design proposals 
-	- `/kind documentation` for PRs releated to documentation 
-	- `/kind failing-test` for PRs releated to to a consistently or frequently failing test 
-	- `/kind flake` for PRs related to a flaky test 
-	- `/kind other` for PRs releated to updating dependencies, minor changes or other 
+	- `/kind feature` for PRs related to adding new features/tests
+	- `/kind bug` for PRs related to bug fixes and patches
+	- `/kind api-change` for PRs related to adding, removing, or otherwise changing an API
+	- `/kind cleanup` for PRs related to code refactoring and cleanup
+	- `/kind deprecation` for PRs related to a feature/enhancement marked for deprecation
+	- `/kind design` for PRs related to design proposals
+	- `/kind documentation` for PRs related to documentation
+	- `/kind failing-test` for PRs related to to a consistently or frequently failing test
+	- `/kind flake` for PRs related to a flaky test
+	- `/kind other` for PRs related to updating dependencies, minor changes or other
     ii.If the PR requires additional action from users switching to a new release, include the string "action required" in the PR release-notes.
     iii.All code changes must be covered by unit tests and E2E tests. iv. All new features should come with user documentation.
 4. Once the PR has been reviewed and is ready to be merged, commits should be [squashed](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md#squash-commits).

docs/book/src/developers/development.md

@@ -70,7 +70,7 @@ Change some code!
 
 This repository uses [Go Modules](https://github.com/golang/go/wiki/Modules) to track vendor dependencies.
 
-To pin a new dependecy:
+To pin a new dependency:
 
 - Run `go get <repository>@<version>`
 - (Optional) Add a replace statement in `go.mod`
@@ -79,7 +79,7 @@ Makefile targets and scripts are offered to work with go modules:
 
 - `make verify-modules` checks whether go modules are out of date.
 - `make modules` runs `go mod tidy` to ensure proper vendoring.
-- `hack/ensure-go.sh` checks that the Go version and enviornment variables are properly set.
+- `hack/ensure-go.sh` checks that the Go version and environment variables are properly set.
 
 ### Setting up the environment
 

docs/book/src/developers/releasing.md

@@ -55,7 +55,7 @@ Create the GitHub release in the UI
 
 ## Versioning
 
-cluster-api-provider-gcp follows the [semantic versionining][semver] specification.
+cluster-api-provider-gcp follows the [semantic versioning][semver] specification.
 
 Example versions:
 - Pre-release: `v0.1.1-alpha.1`