Fix various spelling mistakes

committee-steering/governance/sig-governance-requirements.md

@@ -76,6 +76,6 @@ All technical assets *MUST* be owned by exactly 1 SIG subproject.  The following
 [super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote
 [warnocks-dilemma]: http://communitymgt.wikia.com/wiki/Warnock%27s_Dilemma
 [slo]: https://en.wikipedia.org/wiki/Service_level_objective
-[steering-commitee]: https://github.com/kubernetes/steering#contact
+[steering-committee]: https://github.com/kubernetes/steering#contact
 [business-operations]: http://www.businessdictionary.com/definition/business-operation.html
-[KEP]: https://kubernetes.io/docs/imported/community/keps/
+[KEP]: https://kubernetes.io/docs/imported/community/keps/

contributors/design-proposals/node/disk-accounting.md

@@ -113,7 +113,7 @@ Each container and each image gets own block device. Since this driver works at
 
 Image layers and writable layers are stored under `/var/lib/docker/overlay/<id>`.
 
-Identical files are hardlinked between images.
+Identical files are hard-linked between images.
 
 The image layers contain all their data under a `root` subdirectory.
 
@@ -579,4 +579,3 @@ Capacity in MB = 1638400 * 512 * 128 bytes = 100 GB
 * Overlay storage driver needs kernels >= 3.18. I used Ubuntu 15.10 to test Overlayfs.
 
 * If you use a non-default location for docker storage, change `/var/lib/docker` in the examples to your storage location.
-

contributors/devel/component-config-conventions.md

@@ -36,7 +36,7 @@ Configuration in general has poor qualities such as:
 
 1.  Configuration changes have the same forward/backward compatibility requirements as releases but rollout/rollback of configuration largely untested. Examples of configuration changes that might break a cluster: kubelet CNI plugin, etcd storage version.
 1.  Configuration options often exist only to test a specific feature where the default is reasonable for all real use cases. Examples: many sync periods.
-1.  Configuration options often exist to defer a "hard" design decision and to pay forward the "TODO(someonelse): think critically".
+1.  Configuration options often exist to defer a "hard" design decision and to pay forward the "TODO(someone-else): think critically".
 1.  Configuration options are often used to workaround deficiencies of the API. For example `--register-with-labels` and `--register-with-taints` could be solved with a node initializer, if initializers existed.
 1.  Configuration options often exist to take testing shortcuts. There is a mentality that because a feature is opt-in, it can be released as a flag without robust testing.
 1.  Configuration accumulates new knobs, knobs accumulate new behaviors, knobs are forgotten and bitrot reducing code quality over time.

kubernetes-repositories.md

@@ -36,7 +36,7 @@ To provide a place for SIGs to collaborate on projects endorsed by and actively
    * Must adopt the Kubernetes Code of Conduct
    * All code projects use the Apache License version 2.0. Documentation repositories must use the Creative Commons License version 4.0.
    * Must adopt the CNCF CLA bot, merge bot and Kubernetes PR commands/bots.
-   * All OWNERS of the project must also be active SIG members. 
+   * All OWNERS of the project must also be active SIG members.
    * SIG membership must vote using lazy consensus to create a new repository
    * SIG must already have identified all of their existing subprojects and code, with valid OWNERS files, in [`sigs.yaml`](https://github.com/kubernetes/community/blob/master/sigs.yaml)
 
@@ -97,10 +97,6 @@ We suggest starting with the kubernetes-template-project to ensure you have the
 
 
 
-*Much of the things needed (e.g. CLA Bot integration) is missing to support associated projects. Many things seem vague. Halp!*
+*Much of the things needed (e.g. CLA Bot integration) is missing to support associated projects. Many things seem vague. Help!*
 
 True, we need to improve these things. For now, do the best you can to conform to the spirit of the proposal (e.g. post the code of conduct, etc)
-
-
-
-

org-owners-guide.md

@@ -58,7 +58,7 @@ Each organization should have the following teams:
     a notification mechanism for interested/active contributors for the `foo` repo
 - a `bots` team
   - should contain bots such as @k8s-ci-robot and @linuxfoundation that are
-    neccessary for org and repo automation
+    necessary for org and repo automation
 - an `owners` team
   - should be populated by everyone who has `owner` privileges to the org
   - gives users the opportunity to ping owners as a group rather than having to