Corrected some typos

api_changes.md

@@ -243,7 +243,7 @@ The fuzzer can be found in `pkg/api/testing/fuzzer.go`.
 ## Update the semantic comparisons
 
 VERY VERY rarely is this needed, but when it hits, it hurts.  In some rare
-cases we end up with objects (e.g. resource quantites) that have morally
+cases we end up with objects (e.g. resource quantities) that have morally
 equivalent values with different bitwise representations (e.g. value 10 with a
 base-2 formatter is the same as value 0 with a base-10 formatter).  The only way
 Go knows how to do deep-equality is through field-by-field bitwise comparisons.
@@ -278,7 +278,7 @@ At last, your change is done, all unit tests pass, e2e passes, you're done,
 right?  Actually, no.  You just changed the API.  If you are touching an
 existing facet of the API, you have to try *really* hard to make sure that
 *all* the examples and docs are updated.  There's no easy way to do this, due
-in part ot JSON and YAML silently dropping unknown fields.  You're clever -
+in part to JSON and YAML silently dropping unknown fields.  You're clever -
 you'll figure it out.  Put `grep` or `ack` to good use.
 
 If you added functionality, you should consider documenting it and/or writing

collab.md

@@ -29,7 +29,7 @@ Maintainers will do merges of appropriately reviewed-and-approved changes during
 There may be discussion an even approvals granted outside of the above hours, but merges will generally be deferred.
 
 If a PR is considered complex or controversial, the merge of that PR should be delayed to give all interested parties in all timezones the opportunity to provide feedback.  Concretely, this means that such PRs should be held for 24 
-hours before merging.  Of course "complex" and "controversial" are left to the judgement of the people involved, but we trust that part of being a committer is the judgement required to evaluate such things honestly, and not be
+hours before merging.  Of course "complex" and "controversial" are left to the judgment of the people involved, but we trust that part of being a committer is the judgment required to evaluate such things honestly, and not be
 motivated by your desire (or your cube-mate's desire) to get their code merged.  Also see "Holds" below, any reviewer can issue a "hold" to indicate that the PR is in fact complicated or complex and deserves further review.
 
 PRs that are incorrectly judged to be merge-able, may be reverted and subject to re-review, if subsequent reviewers believe that they in fact are controversial or complex.

development.md

@@ -221,7 +221,7 @@ go run hack/e2e.go -build -pushup -test -down
 # seeing the output of failed commands.
 
 # -ctl can be used to quickly call kubectl against your e2e cluster. Useful for
-# cleaning up after a failed test or viewing logs. Use -v to avoid supressing
+# cleaning up after a failed test or viewing logs. Use -v to avoid suppressing
 # kubectl output.
 go run hack/e2e.go -v -ctl='get events'
 go run hack/e2e.go -v -ctl='delete pod foobar'

faster_reviews.md

@@ -135,7 +135,7 @@ might need later - but don't implement them now.
 
 We understand that it is hard to imagine, but sometimes we make mistakes.  It's
 OK to push back on changes requested during a review.  If you have a good reason
-for doing something a certain way, you are absolutley allowed to debate the
+for doing something a certain way, you are absolutely allowed to debate the
 merits of a requested change.  You might be overruled, but you might also
 prevail.  We're mostly pretty reasonable people.  Mostly.
 
@@ -151,7 +151,7 @@ things you can do that might help kick a stalled process along:
    * Ping the assignee (@username) on the PR comment stream asking for an
      estimate of when they can get to it.
 
-   * Ping the assigneed by email (many of us have email addresses that are well
+   * Ping the assignee by email (many of us have email addresses that are well
      published or are the same as our GitHub handle @google.com or @redhat.com).
 
 If you think you have fixed all the issues in a round of review, and you haven't
@@ -171,7 +171,7 @@ explanation.
 ## Final: Use common sense
 
 Obviously, none of these points are hard rules.  There is no document that can
-take the place of common sense and good taste.  Use your best judgement, but put
+take the place of common sense and good taste.  Use your best judgment, but put
 a bit of thought into how your work can be made easier to review.  If you do
 these things your PRs will flow much more easily.
 

logging.md

@@ -1,7 +1,7 @@
 Logging Conventions
 ===================
 
-The following conventions for the glog levels to use.  [glog](http://godoc.org/github.com/golang/glog) is globally prefered to [log](http://golang.org/pkg/log/) for better runtime control.
+The following conventions for the glog levels to use.  [glog](http://godoc.org/github.com/golang/glog) is globally preferred to [log](http://golang.org/pkg/log/) for better runtime control.
 
 * glog.Errorf() - Always an error
 * glog.Warningf() - Something unexpected, but probably not an error

profiling.md

@@ -4,7 +4,7 @@ This document explain how to plug in profiler and how to profile Kubernetes serv
 
 ## Profiling library
 
-Go comes with inbuilt 'net/http/pprof' profiling library and profiling web service. The way service works is binding debug/pprof/ subtree on a running webserver to the profiler. Reading from subpages of debug/pprof returns pprof-formated profiles of the running binary. The output can be processed offline by the tool of choice, or used as an input to handy 'go tool pprof', which can graphically represent the result.
+Go comes with inbuilt 'net/http/pprof' profiling library and profiling web service. The way service works is binding debug/pprof/ subtree on a running webserver to the profiler. Reading from subpages of debug/pprof returns pprof-formatted profiles of the running binary. The output can be processed offline by the tool of choice, or used as an input to handy 'go tool pprof', which can graphically represent the result.
 
 ## Adding profiling to services to APIserver.
 
@@ -31,4 +31,4 @@ to get 30 sec. CPU profile.
 
 ## Contention profiling
 
-To enable contetion profiling you need to add line ```rt.SetBlockProfileRate(1)``` in addition to ```m.mux.HandleFunc(...)``` added before (```rt``` stands for ```runtime``` in ```master.go```). This enables 'debug/pprof/block' subpage, which can be used as an input to ```go tool pprof```.
+To enable contention profiling you need to add line ```rt.SetBlockProfileRate(1)``` in addition to ```m.mux.HandleFunc(...)``` added before (```rt``` stands for ```runtime``` in ```master.go```). This enables 'debug/pprof/block' subpage, which can be used as an input to ```go tool pprof```.

releasing.md

@@ -92,7 +92,7 @@ get` while in fact they do not match `v0.5` (the one that was tagged) exactly.
 To handle that case, creating a new release should involve creating two adjacent
 commits where the first of them will set the version to `v0.5` and the second
 will set it to `v0.5-dev`. In that case, even in the presence of merges, there
-will be a single comit where the exact `v0.5` version will be used and all
+will be a single commit where the exact `v0.5` version will be used and all
 others around it will either have `v0.4-dev` or `v0.5-dev`.
 
 The diagram below illustrates it.

writing-a-getting-started-guide.md

@@ -6,7 +6,7 @@ guide.
 A Getting Started Guide is instructions on how to create a Kubernetes cluster on top of a particular
 type(s) of infrastructure.  Infrastructure includes: the IaaS provider for VMs;
 the node OS; inter-node networking; and node Configuration Management system.
-A guide refers to scripts, Configuration Manangement files, and/or binary assets such as RPMs.  We call
+A guide refers to scripts, Configuration Management files, and/or binary assets such as RPMs.  We call
 the combination of all these things needed to run on a particular type of infrastructure a
 **distro**.
 
@@ -39,7 +39,7 @@ These guidelines say *what* to do.  See the Rationale section for *why*.
        that are updated to the new version.
  - Versioned distros should typically not modify or add code in `cluster/`.  That is just scripts for developer
    distros.  
- - If a versioned distro has not been updated for many binary releases, it may be dropped frome the Matrix.
+ - If a versioned distro has not been updated for many binary releases, it may be dropped from the Matrix.
 
 If you have a cluster partially working, but doing all the above steps seems like too much work,
 we still want to hear from you.  We suggest you write a blog post or a Gist, and we will link to it on our wiki page.
@@ -58,13 +58,13 @@ These guidelines say *what* to do.  See the Rationale section for *why*.
   - a development distro needs to have an organization which owns it.  This organization needs to: 
     - Setting up and maintaining Continuous Integration that runs e2e frequently (multiple times per day) against the
       Distro at head,  and which notifies all devs of breakage.
-    - being reasonably available for questions and assiting with
+    - being reasonably available for questions and assisting with
       refactoring and feature additions that affect code for their IaaS.
 
 ## Rationale 
  - We want want people to create Kubernetes clusters with whatever IaaS, Node OS,
    configuration management tools, and so on, which they are familiar with.  The
-   guidelines for **versioned distros** are designed for flexiblity.
+   guidelines for **versioned distros** are designed for flexibility.
  - We want developers to be able to work without understanding all the permutations of
    IaaS, NodeOS, and configuration management.  The guidelines for **developer distros** are designed
    for consistency.