Doc spelling corrections

docs/concepts.rst

@@ -32,7 +32,7 @@ What is a channel? It is an *ordered*, *first-in first-out queue* with
 
 You can think of it as analogous to a task queue - messages are put onto
 the channel by *producers*, and then given to just one of the *consumers*
-listening to that channnel.
+listening to that channel.
 
 By *at-most-once* we say that either one consumer gets the message or nobody
 does (if the channel implementation crashes, let's say). The

docs/cross-compat.rst

@@ -1,4 +1,4 @@
-Cross-Compatability
+Cross-Compatibility
 ===================
 
 Channels is being released as both a third-party app for Django 1.8 and 1.9,

docs/deploying.rst

@@ -86,7 +86,7 @@ the same workers as HTTP requests, there's a chance long-running tasks could
 block up all the workers and delay responding to HTTP requests).
 
 To manage this, it's possible to tell workers to either limit themselves to
-just certain channel names or ignore sepcific channels using the
+just certain channel names or ignore specific channels using the
 ``--only-channels`` and ``--exclude-channels`` options. Here's an example
 of configuring a worker to only serve HTTP and WebSocket requests::
 
@@ -166,7 +166,7 @@ rollouts to make sure workers on new code aren't experiencing high error rates.
 There's no need to restart the WSGI or WebSocket interface servers unless
 you've upgraded your version of Channels or changed any settings;
 none of your code is used by them, and all middleware and code that can
-customise requests is run on the consumers.
+customize requests is run on the consumers.
 
 You can even use different Python versions for the interface servers and the
 workers; the ASGI protocol that channel layers communicate over

docs/getting-started.rst

@@ -182,7 +182,7 @@ of the time anyway.
     on 100% guaranteed delivery, which Channels won't give you, look at each
     failure case and program something to expect and handle it - be that retry
     logic, partial content handling, or just having something not work that one
-    time. HTTP requests are just as fallible, and most people's reponse to that
+    time. HTTP requests are just as fallible, and most people's response to that
     is a generic error page!
 
 .. _websocket-example:

docs/testing.rst

@@ -2,7 +2,7 @@ Testing Consumers
 =================
 
 When you want to write unit tests for your new Channels consumers, you'll
-realise that you can't use the standard Django test client to submit fake HTTP
+realize that you can't use the standard Django test client to submit fake HTTP
 requests - instead, you'll need to submit fake Messages to your consumers,
 and inspect what Messages they send themselves.
 
@@ -15,7 +15,7 @@ ChannelTestCase
 
 If your tests inherit from the ``channels.tests.ChannelTestCase`` base class,
 whenever you run tests your channel layer will be swapped out for a captive
-in-memory layer, meaning you don't need an exernal server running to run tests.
+in-memory layer, meaning you don't need an external server running to run tests.
 
 Moreover, you can inject messages onto this layer and inspect ones sent to it
 to help test your consumers.