diff --git a/doc/deployment-philosophy.rst b/doc/deployment-philosophy.rst
index 87ed2195e8..f6842ddde7 100644
--- a/doc/deployment-philosophy.rst
+++ b/doc/deployment-philosophy.rst
@@ -7,18 +7,18 @@ Kolla's Deployment Philosophy
 Overview
 ========
 
-Kolla has an objective to replace the inflexible, painful, resource intensive
+Kolla has an objective to replace the inflexible, painful, resource-intensive
 deployment process of OpenStack with a flexible, painless, inexpensive
-deployment process. Often to deploy OpenStack at one-hundred node scale that
-a small business may require means building a team of OpenStack professionals
-to maintain and manage the OpenStack deployment. Finding people experienced
-in OpenStack deployment is very difficult and expensive, resulting in a big
+deployment process. Often to deploy OpenStack at the 100+ node scale small
+businesses may require means building a team of OpenStack professionals to
+maintain and manage the OpenStack deployment. Finding people experienced in
+OpenStack deployment is very difficult and expensive, resulting in a big
 barrier for OpenStack adoption. Kolla seeks to remedy this set of problems by
 simplifying the deployment process but enabling flexible deployment models.
 
 Kolla is a highly opinionated deployment tool out of the box. This permits
-Kolla to be deployable with configuration of three key/value pairs. As an
-operator's experience with OpenStack grows and the desire to customize
+Kolla to be deployable with the simple configuration of three key/value pairs.
+As an operator's experience with OpenStack grows and the desire to customize
 OpenStack services increases, Kolla offers full capability to override every
 OpenStack service configuration option in the deployment.
 
@@ -33,8 +33,8 @@ grow to hundreds of configuration key/value pairs which is unmanageable.
 Further, as new versions of Kolla are released, there would be independent
 customization available for different versions creating an unsupportable and
 difficult to document environment. Finally, adding key/value pairs for
-configuration options creates a situation in which a development and release
-cycle is required in order to successfully add a new customization.
+configuration options creates a situation in which development and release
+cycles are required in order to successfully add new customizations.
 Essentially templating in configuration options is not a scalable solution
 and would result in an inability of the project to execute its mission.
 
@@ -43,14 +43,15 @@ Kolla's Solution to Customization
 
 Rather than deal with the customization madness of templating configuration
 options in Kolla's Ansible playbooks, Kolla eliminates all the inefficiencies
-of existing deployment tools through a tidy simple design.
+of existing deployment tools through a simple, tidy design: custom
+configuration sections.
 
 During deployment of an OpenStack service, a basic set of default configuration
 options are merged with and overridden by custom ini configuration sections.
 Kolla deployment customization is that simple! This does create a situation
-in which the Operator references the upstream documentation if a customization
-is desired in the OpenStack deployment. Fortunately the configuration options
-documentation is extremely mature and well-formulated.
+in which the Operator must reference the upstream documentation if a
+customization is desired in the OpenStack deployment. Fortunately the
+configuration options documentation is extremely mature and well-formulated.
 
 As an example, consider running Kolla in a virtual machine. In order to
 launch virtual machines from Nova in a virtual environment, it is necessary