fix(docs): minor spelling corrections (#544)

* fix(docs): minor grammar fix

* fix(docs): minor spelling corrections

* fix(docs): minor spelling corrections

* fix(docs): minor spelling corrections

* fix(docs): minor spelling corrections

* fix(docs): minor spelling corrections

* fix(docs): minor spelling corrections

* fix(docs): minor spelling corrections

* fix(docs): minor spelling corrections

src/applications/managing-app-lifecycle.md

@@ -6,7 +6,7 @@ Deis Workflow tracks all changes to your application. Application changes are th
 pushed to the platform (via `git push deis master`), or an update to application configuration (via `deis config:set KEY=VAL`).
 
 Each time a build or config change is made to your application a new [release][] is created. These release numbers
-increase montonically.
+increase monotonically.
 
 You can see a record of changes to your application using `deis releases`:
 

src/applications/managing-app-processes.md

@@ -1,7 +1,7 @@
 # Managing Application Processes
 
 Deis Workflow manages your application as a set of processes that can be named, scaled and configured according to their
-role. This gives you the flexiblity to easily manage the different facets of your application. For example, you may have
+role. This gives you the flexibility to easily manage the different facets of your application. For example, you may have
 web-facing processes that handle HTTP traffic, background worker processes that do async work, and a helper process that
 streams from the Twitter API.
 
@@ -124,7 +124,7 @@ iciest-waggoner-web-3291896318-kt7vu up (v2)
 ```
 
 If you have multiple process types for your application you may scale the process count for each type separately. For
-example, this allows you to manage web process indepenetly from background workers. For more information on process
+example, this allows you to manage web process independently from background workers. For more information on process
 types see our documentation for [Managing App Processes](managing-app-processes.md).
 
 In this example, we are scaling the process type `web` to 5 but leaving the process type `background` with one worker.

src/applications/ssl-certificates.md

@@ -49,7 +49,7 @@ Add your certificate, any intermediate certificates, and private key to the endp
     www.example.com
 
 !!! note
-    The name given to the certificate can only contain a-z (lowercase), 0-9 and hypens
+    The name given to the certificate can only contain a-z (lowercase), 0-9 and hyphens
 
 The Deis platform will investigate the certificate and extract any relevant information from it
 such as the Common Name, Subject Alt Names (SAN), fingerprint and more.
@@ -72,7 +72,7 @@ After that, you can add them to Deis with the `certs:add` command:
 
 ## Attach SSL certificate to a domain
 
-Certificates are not automagically conneced up to domains, instead you will have to attach a
+Certificates are not automagically connected up to domains, instead you will have to attach a
 certificate to a domain
 
     $ deis certs:attach example-com example.com

src/contributing/development-environment.md

@@ -77,13 +77,13 @@ $ eval "$(docker-machine env docker-deis)"
 After following these steps, some Docker Machine users report a slight delay (30 - 60 seconds) before the Docker server is ready.
 
 !!! note
-    In subsequent steps, you may run a Docker registry within the `deis-docker` VM. Such a registry will not have a valid SSL certificate and will use HTTP instead of HTTPS. Such registries are implicitly untrusted by the Docker server (which is also running on the `deis-docker` VM).  In order for the Docker server to trust the insecure registry, `deis-docker` is explicitly created to trust all registries in the IP ranges that that are reserved for use by provate networks.  The VM (and therefore the registry) will exist within such a range.  This will effectively permit Docker pulls and pushes to such a registry.
+    In subsequent steps, you may run a Docker registry within the `deis-docker` VM. Such a registry will not have a valid SSL certificate and will use HTTP instead of HTTPS. Such registries are implicitly untrusted by the Docker server (which is also running on the `deis-docker` VM).  In order for the Docker server to trust the insecure registry, `deis-docker` is explicitly created to trust all registries in the IP ranges that that are reserved for use by private networks.  The VM (and therefore the registry) will exist within such a range.  This will effectively permit Docker pulls and pushes to such a registry.
 
 ## Fork the Repository
 
 Once the prerequisites have been met, we can begin to work with Deis components.
 
-Begin at Github by forking whichever Deis project you would like to contriubte to, then clone that fork locally.  Since Deis is predominantly written in Go, the best place to put it is under `$GOPATH/src/github.com/deis/`.
+Begin at Github by forking whichever Deis project you would like to contribute to, then clone that fork locally.  Since Deis is predominantly written in Go, the best place to put it is under `$GOPATH/src/github.com/deis/`.
 
 ```
 $ mkdir -p  $GOPATH/src/github.com/deis

src/contributing/testing.md

@@ -4,7 +4,7 @@ Each Deis component is one among an ecosystem of such components - many of which
 
 Each Deis component includes its own suite of style checks, [unit tests][], and black-box type [functional tests][].
 
-[Integration tests][] verify the behavior of the Deis components together as a system and are provided separatley by the [deis/workflow-e2e][workflow-e2e] project.
+[Integration tests][] verify the behavior of the Deis components together as a system and are provided separately by the [deis/workflow-e2e][workflow-e2e] project.
 
 GitHub pull requests for all Deis components are tested automatically by the [Travis CI][travis] [continuous integration][] system. Contributors should run the same tests locally before proposing any changes to the Deis codebase.
 

src/contributing/triaging-issues.md

@@ -17,7 +17,7 @@ Before triaging an issue very far, make sure that the issue's author provided th
 -   a reproducible case if this is a bug
 -   page URL if this is a docs issue or the name of a man page
 
-Depending on the issue, you might not feel all this information is needed. Use your best judgement.  If you cannot triage an issue using what its author provided, explain kindly to the author that they must provide the above information to clarify the problem.
+Depending on the issue, you might not feel all this information is needed. Use your best judgment. If you cannot triage an issue using what its author provided, explain kindly to the author that they must provide the above information to clarify the problem.
 
 If the author provides the recommended information but you are still unable to triage the issue, request additional information. Do this kindly and politely because you are asking for more of the author's time.
 

src/managing-workflow/configuring-load-balancers.md

@@ -10,7 +10,7 @@ If, for instance, Deis Workflow were installed on kube-aws, this timeout should
 
 ## Configuring PROXY protocol
 
-By default Kubernetes will create an external TCP load balancer to route incoming requests to the Deis router, which will take care of forwarding the requests to the right application inside the cluster depending on the hostname. Because the original request is not modified by the load balancer, the router only knowns about the internal IP address of the load balancer which will then be forwarded to your app in the `X-Forwarded-For` HTTP header.
+By default Kubernetes will create an external TCP load balancer to route incoming requests to the Deis router, which will take care of forwarding the requests to the right application inside the cluster depending on the hostname. Because the original request is not modified by the load balancer, the router only knows about the internal IP address of the load balancer which will then be forwarded to your app in the `X-Forwarded-For` HTTP header.
 
 If you need access to the *actual* client's IP address in your application, for example for IP-based sessions, access control or auditing, you need to configure the external load balancer and the Deis router to use the [PROXY protocol](http://www.haproxy.org/download/1.6/doc/proxy-protocol.txt). The PROXY protocol adds a small header with the client's IP address to each connection, which can then be used by the Deis router to pass the actual client IP in the `X-Forwarded-For` HTTP header.
 

src/managing-workflow/platform-monitoring.md

@@ -74,7 +74,7 @@ following line - `router.deis.io/routable: "true"`.
 Telegraf is the metrics collection daemon used within the monitoring stack. It will collect and send the following metrics to InfluxDB:
 
 * System level metrics such as CPU, Load Average, Memory, Disk, and Network stats
-* Container level memtrics such as CPU and Memory
+* Container level metrics such as CPU and Memory
 * Kubernetes metrics such as API request latency, Pod Startup Latency, and number of running pods
 
 It is possible to send these metrics to other endpoints besides InfluxDB. For more information please consult the following [file](https://github.com/deis/monitor/blob/master/telegraf/rootfs/config.toml.tpl)

src/users/registration.md

@@ -21,7 +21,7 @@ to create a new account. After successful registration you will be logged in as
     Logged in as myuser
 
 !!! important
-    The first user to register with Deis Workflow is automatically becomes an administrator. Additional users who register will be ordinary users.
+    The first user to register with Deis Workflow automatically becomes an administrator. Additional users who register will be ordinary users.
 
 ## Login to Workflow