diff --git a/doc/source/guides/devstack-with-nested-kvm.rst b/doc/source/guides/devstack-with-nested-kvm.rst
index 610300b..b35492e 100644
--- a/doc/source/guides/devstack-with-nested-kvm.rst
+++ b/doc/source/guides/devstack-with-nested-kvm.rst
@@ -54,7 +54,7 @@
 
 
 Configure Nested KVM for AMD-based Machines
---------------------------------------------
+-------------------------------------------
 
 Procedure to enable nested KVM virtualization on AMD-based machines.
 
@@ -121,7 +121,7 @@
 back to `virt_type=qemu`, i.e. plain QEMU emulation.
 
 Optionally, to explicitly set the type of virtualization, to KVM, by the
-libvirt driver in Nova, the below config attribute can be used in
+libvirt driver in nova, the below config attribute can be used in
 DevStack's ``local.conf``:
 
 ::
diff --git a/doc/source/guides/multinode-lab.rst b/doc/source/guides/multinode-lab.rst
index d963243..b2617c9 100644
--- a/doc/source/guides/multinode-lab.rst
+++ b/doc/source/guides/multinode-lab.rst
@@ -262,17 +262,17 @@
 Swift
 -----
 
-Swift requires a significant amount of resources and is disabled by
-default in DevStack. The support in DevStack is geared toward a minimal
-installation but can be used for testing. To implement a true multi-node
-test of Swift required more than DevStack provides. Enabling it is as
+Swift, OpenStack Object Storage, requires a significant amount of resources
+and is disabled by default in DevStack. The support in DevStack is geared 
+toward a minimal installation but can be used for testing. To implement a
+true multi-node test of swift, additional steps will be required. Enabling it is as
 simple as enabling the ``swift`` service in ``local.conf``:
 
 ::
 
     enable_service s-proxy s-object s-container s-account
 
-Swift will put its data files in ``SWIFT_DATA_DIR`` (default
+Swift, OpenStack Object Storage, will put its data files in ``SWIFT_DATA_DIR`` (default
 ``/opt/stack/data/swift``). The size of the data 'partition' created
 (really a loop-mounted file) is set by ``SWIFT_LOOPBACK_DISK_SIZE``. The
 Swift config files are located in ``SWIFT_CONF_DIR`` (default
@@ -334,14 +334,14 @@
 set in ``localrc`` it may be necessary to remove the corresponding
 directory from ``/opt/stack`` to force git to re-clone the repository.
 
-For example, to pull Nova from a proposed release candidate in the
-primary Nova repository:
+For example, to pull nova, OpenStack Compute, from a proposed release candidate
+in the primary nova repository:
 
 ::
 
     NOVA_BRANCH=rc-proposed
 
-To pull Glance from an experimental fork:
+To pull glance, OpenStack Image service, from an experimental fork:
 
 ::
 
diff --git a/doc/source/guides/neutron.rst b/doc/source/guides/neutron.rst
index 95cde96..3030c7b 100644
--- a/doc/source/guides/neutron.rst
+++ b/doc/source/guides/neutron.rst
@@ -1,14 +1,14 @@
 ======================================
-Using DevStack with Neutron Networking
+Using DevStack with neutron Networking
 ======================================
 
-This guide will walk you through using OpenStack Neutron with the ML2
+This guide will walk you through using OpenStack neutron with the ML2
 plugin and the Open vSwitch mechanism driver.
 
 Network Interface Configuration
 ===============================
 
-To use Neutron, it is suggested that two network interfaces be present
+To use neutron, it is suggested that two network interfaces be present
 in the host operating system.
 
 The first interface, eth0 is used for the OpenStack management (API,
@@ -62,7 +62,7 @@
 Disabling Next Generation Firewall Tools
 ========================================
 
-Devstack does not properly operate with modern firewall tools.  Specifically
+DevStack does not properly operate with modern firewall tools.  Specifically
 it will appear as if the guest VM can access the external network via ICMP,
 but UDP and TCP packets will not be delivered to the guest VM.  The root cause
 of the issue is that both ufw (Uncomplicated Firewall) and firewalld (Fedora's
@@ -96,13 +96,13 @@
 Neutron Networking with Open vSwitch
 ====================================
 
-Configuring Neutron networking in DevStack is very similar to
+Configuring neutron, OpenStack Networking in DevStack is very similar to
 configuring `nova-network` - many of the same configuration variables
 (like `FIXED_RANGE` and `FLOATING_RANGE`) used by `nova-network` are
-used by Neutron, which is intentional.
+used by neutron, which is intentional.
 
 The only difference is the disabling of `nova-network` in your
-local.conf, and the enabling of the Neutron components.
+local.conf, and the enabling of the neutron components.
 
 
 Configuration
@@ -134,16 +134,16 @@
 Neutron Networking with Open vSwitch and Provider Networks
 ==========================================================
 
-In some instances, it is desirable to use Neutron's provider
+In some instances, it is desirable to use neutron's provider
 networking extension, so that networks that are configured on an
-external router can be utilized by Neutron, and instances created via
+external router can be utilized by neutron, and instances created via
 Nova can attach to the network managed by the external router.
 
 For example, in some lab environments, a hardware router has been
 pre-configured by another party, and an OpenStack developer has been
 given a VLAN tag and IP address range, so that instances created via
 DevStack will use the external router for L3 connectivity, as opposed
-to the Neutron L3 service.
+to the neutron L3 service.
 
 
 Service Configuration
@@ -152,8 +152,8 @@
 **Control Node**
 
 In this example, the control node will run the majority of the
-OpenStack API and management services (Keystone, Glance,
-Nova, Neutron, etc..)
+OpenStack API and management services (keystone, glance,
+nova, neutron)
 
 
 **Compute Nodes**
@@ -226,4 +226,4 @@
 For example, with the above  configuration, a bridge is
 created, named `br-ex` which is managed by Open vSwitch, and the
 second interface on the compute node, `eth1` is attached to the
-bridge, to forward traffic sent by guest vms.
+bridge, to forward traffic sent by guest VMs.
diff --git a/doc/source/guides/nova.rst b/doc/source/guides/nova.rst
index 0d98f4a..a91e0d1 100644
--- a/doc/source/guides/nova.rst
+++ b/doc/source/guides/nova.rst
@@ -1,15 +1,15 @@
 =================
-Nova and devstack
+Nova and DevStack
 =================
 
 This is a rough guide to various configuration parameters for nova
-running with devstack.
+running with DevStack.
 
 
 nova-serialproxy
 ================
 
-In Juno nova implemented a `spec
+In Juno, nova implemented a `spec
 <http://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/serial-ports.html>`_
 to allow read/write access to the serial console of an instance via
 `nova-serialproxy
@@ -60,7 +60,7 @@
     #proxyclient_address=127.0.0.1
 
 
-Enabling the service is enough to be functional for a single machine devstack.
+Enabling the service is enough to be functional for a single machine DevStack.
 
 These config options are defined in `nova.console.serial
 <https://github.com/openstack/nova/blob/master/nova/console/serial.py#L33-L52>`_
diff --git a/doc/source/guides/single-vm.rst b/doc/source/guides/single-vm.rst
index ab46d91..c2ce1a3 100644
--- a/doc/source/guides/single-vm.rst
+++ b/doc/source/guides/single-vm.rst
@@ -3,10 +3,10 @@
 ====================
 
 Use the cloud to build the cloud! Use your cloud to launch new versions
-of OpenStack in about 5 minutes. When you break it, start over! The VMs
+of OpenStack in about 5 minutes. If you break it, start over! The VMs
 launched in the cloud will be slow as they are running in QEMU
 (emulation), but their primary use is testing OpenStack development and
-operation. Speed not required.
+operation.
 
 Prerequisites Cloud & Image
 ===========================
@@ -15,7 +15,7 @@
 ---------------
 
 DevStack should run in any virtual machine running a supported Linux
-release. It will perform best with 4Gb or more of RAM.
+release. It will perform best with 4GB or more of RAM.
 
 OpenStack Deployment & cloud-init
 ---------------------------------
@@ -88,7 +88,7 @@
 ---------------
 
 At this point you should be able to access the dashboard. Launch VMs and
-if you give them floating IPs access those VMs from other machines on
+if you give them floating IPs, access those VMs from other machines on
 your network.
 
 One interesting use case is for developers working on a VM on their