diff --git a/docs/execution/dataloader.rst b/docs/execution/dataloader.rst
index 3f693075f..8a8e2ae3e 100644
--- a/docs/execution/dataloader.rst
+++ b/docs/execution/dataloader.rst
@@ -28,10 +28,9 @@ Create loaders by providing a batch loading function.
 A batch loading function accepts a list of keys, and returns a ``Promise``
 which resolves to a list of ``values``.
 
-Then load individual values from the loader. ``DataLoader`` will coalesce all
-individual loads which occur within a single frame of execution (executed once
-the wrapping promise is resolved) and then call your batch function with all
-requested keys.
+``DataLoader`` will coalesce all individual loads which occur within a
+single frame of execution (executed once the wrapping promise is resolved)
+and then call your batch function with all requested keys.
 
 
 .. code:: python
@@ -96,7 +95,7 @@ Consider the following GraphQL request:
     }
 
 
-Naively, if ``me``, ``bestFriend`` and ``friends`` each need to request the backend,
+If ``me``, ``bestFriend`` and ``friends`` each need to send a request to the backend,
 there could be at most 13 database requests!
 
 
diff --git a/docs/execution/middleware.rst b/docs/execution/middleware.rst
index 0c5458b20..c0a8c7929 100644
--- a/docs/execution/middleware.rst
+++ b/docs/execution/middleware.rst
@@ -46,7 +46,7 @@ Functional example
 ------------------
 
 Middleware can also be defined as a function. Here we define a middleware that
-logs the time it takes to resolve each field
+logs the time it takes to resolve each field:
 
 .. code:: python
 
diff --git a/docs/types/interfaces.rst b/docs/types/interfaces.rst
index eb7172e9e..4d4e32a56 100644
--- a/docs/types/interfaces.rst
+++ b/docs/types/interfaces.rst
@@ -44,7 +44,7 @@ Both of these types have all of the fields from the ``Character`` interface,
 but also bring in extra fields, ``home_planet``, ``starships`` and
 ``primary_function``, that are specific to that particular type of character.
 
-The full GraphQL schema defition will look like this:
+The full GraphQL schema definition will look like this:
 
 .. code::
 
diff --git a/docs/types/mutations.rst b/docs/types/mutations.rst
index f8c76f350..738660632 100644
--- a/docs/types/mutations.rst
+++ b/docs/types/mutations.rst
@@ -85,9 +85,9 @@ We should receive:
 
 InputFields and InputObjectTypes
 ----------------------------------
-InputFields are used in mutations to allow nested input data for mutations
+InputFields are used in mutations to allow nested input data for mutations.
 
-To use an InputField you define an InputObjectType that specifies the structure of your input data
+To use an InputField you define an InputObjectType that specifies the structure of your input data:
 
 
 .. code:: python
@@ -112,7 +112,7 @@ To use an InputField you define an InputObjectType that specifies the structure
             return CreatePerson(person=person)
 
 
-Note that  **name** and **age** are part of **person_data** now
+Note that  **name** and **age** are part of **person_data** now.
 
 Using the above mutation your new query would look like this:
 
@@ -128,7 +128,7 @@ Using the above mutation your new query would look like this:
     }
 
 InputObjectTypes can also be fields of InputObjectTypes allowing you to have
-as complex of input data as you need
+as complex of input data as you need:
 
 .. code:: python
 
@@ -160,7 +160,7 @@ To return an existing ObjectType instead of a mutation-specific type, set the **
         def mutate(root, info, name):
             return Person(name=name)
 
-Then, if we query (``schema.execute(query_str)``) the following:
+Then, if we query (``schema.execute(query_str)``) with the following:
 
 .. code::
 
diff --git a/docs/types/schema.rst b/docs/types/schema.rst
index 08ff27d04..a82addc9a 100644
--- a/docs/types/schema.rst
+++ b/docs/types/schema.rst
@@ -44,7 +44,7 @@ There are some cases where the schema cannot access all of the types that we pla
 For example, when a field returns an ``Interface``, the schema doesn't know about any of the
 implementations.
 
-In this case, we need to use the ``types`` argument when creating the Schema.
+In this case, we need to use the ``types`` argument when creating the Schema:
 
 
 .. code:: python
@@ -63,7 +63,7 @@ By default all field and argument names (that are not
 explicitly set with the ``name`` arg) will be converted from
 ``snake_case`` to ``camelCase`` (as the API is usually being consumed by a js/mobile client)
 
-For example with the ObjectType
+For example with the ObjectType the ``last_name`` field name is converted to ``lastName``:
 
 .. code:: python
 
@@ -71,12 +71,10 @@ For example with the ObjectType
         last_name = graphene.String()
         other_name = graphene.String(name='_other_Name')
 
-the ``last_name`` field name is converted to ``lastName``.
-
 In case you don't want to apply this transformation, provide a ``name`` argument to the field constructor.
 ``other_name`` converts to ``_other_Name`` (without further transformations).
 
-Your query should look like
+Your query should look like:
 
 .. code::
 
@@ -86,7 +84,7 @@ Your query should look like
     }
 
 
-To disable this behavior, set the ``auto_camelcase`` to ``False`` upon schema instantiation.
+To disable this behavior, set the ``auto_camelcase`` to ``False`` upon schema instantiation:
 
 .. code:: python
 
diff --git a/docs/types/unions.rst b/docs/types/unions.rst
index 2c5c5a756..16ac24e87 100644
--- a/docs/types/unions.rst
+++ b/docs/types/unions.rst
@@ -7,7 +7,7 @@ to specify any common fields between the types.
 The basics:
 
 - Each Union is a Python class that inherits from ``graphene.Union``.
-- Unions don't have any fields on it, just links to the possible objecttypes.
+- Unions don't have any fields on it, just links to the possible ObjectTypes.
 
 Quick example
 -------------