diff --git a/doc/source/plugin.rst b/doc/source/plugin.rst
index 6f6621d..9958792 100644
--- a/doc/source/plugin.rst
+++ b/doc/source/plugin.rst
@@ -5,24 +5,24 @@
 =============================
 
 Tempest has an external test plugin interface which enables anyone to integrate
-an external test suite as part of a tempest run. This will let any project
-leverage being run with the rest of the tempest suite while not requiring the
-tests live in the tempest tree.
+an external test suite as part of a Tempest run. This will let any project
+leverage being run with the rest of the Tempest suite while not requiring the
+tests live in the Tempest tree.
 
 Creating a plugin
 =================
 
 Creating a plugin is fairly straightforward and doesn't require much additional
 effort on top of creating a test suite using tempest.lib. One thing to note with
-doing this is that the interfaces exposed by tempest are not considered stable
-(with the exception of configuration variables which ever effort goes into
-ensuring backwards compatibility). You should not need to import anything from
-tempest itself except where explicitly noted.
+doing this is that the interfaces exposed by Tempest are not considered stable
+(with the exception of configuration variables whichever effort goes into
+ensuring backward compatibility). You should not need to import anything from
+Tempest itself except where explicitly noted.
 
 Stable Tempest APIs plugins may use
 -----------------------------------
 
-As noted above, several tempest APIs are acceptable to use from plugins, while
+As noted above, several Tempest APIs are acceptable to use from plugins, while
 others are not. A list of stable APIs available to plugins is provided below:
 
 * tempest.lib.*
@@ -32,7 +32,7 @@
 * tempest.clients
 * tempest.test
 
-If there is an interface from tempest that you need to rely on in your plugin
+If there is an interface from Tempest that you need to rely on in your plugin
 which is not listed above, it likely needs to be migrated to tempest.lib. In
 that situation, file a bug, push a migration patch, etc. to expedite providing
 the interface in a reliable manner.
@@ -62,7 +62,7 @@
 -----------
 
 Once you've created your plugin class you need to add an entry point to your
-project to enable tempest to find the plugin. The entry point must be added
+project to enable Tempest to find the plugin. The entry point must be added
 to the "tempest.test_plugins" namespace.
 
 If you are using pbr this is fairly straightforward, in the setup.cfg just add
@@ -77,9 +77,9 @@
 Standalone Plugin vs In-repo Plugin
 -----------------------------------
 
-Since all that's required for a plugin to be detected by tempest is a valid
+Since all that's required for a plugin to be detected by Tempest is a valid
 setuptools entry point in the proper namespace there is no difference from the
-tempest perspective on either creating a separate python package to
+Tempest perspective on either creating a separate python package to
 house the plugin or adding the code to an existing python project. However,
 there are tradeoffs to consider when deciding which approach to take when
 creating a new plugin.
@@ -91,9 +91,9 @@
 single version of the test code across project release boundaries (see the
 `Branchless Tempest Spec`_ for more details on this). It also greatly
 simplifies the install time story for external users. Instead of having to
-install the right version of a project in the same python namespace as tempest
+install the right version of a project in the same python namespace as Tempest
 they simply need to pip install the plugin in that namespace. It also means
-that users don't have to worry about inadvertently installing a tempest plugin
+that users don't have to worry about inadvertently installing a Tempest plugin
 when they install another package.
 
 .. _Branchless Tempest Spec: http://specs.openstack.org/openstack/qa-specs/specs/tempest/implemented/branchless-tempest.html
@@ -108,9 +108,9 @@
 Plugin Class
 ============
 
-To provide tempest with all the required information it needs to be able to run
-your plugin you need to create a plugin class which tempest will load and call
-to get information when it needs. To simplify creating this tempest provides an
+To provide Tempest with all the required information it needs to be able to run
+your plugin you need to create a plugin class which Tempest will load and call
+to get information when it needs. To simplify creating this Tempest provides an
 abstract class that should be used as the parent for your plugin. To use this
 you would do something like the following:
 
@@ -147,7 +147,7 @@
       services/
         client.py
 
-That will mirror what people expect from tempest. The file
+That will mirror what people expect from Tempest. The file
 
 * **config.py**: contains any plugin specific configuration variables
 * **plugin.py**: contains the plugin class used for the entry point
@@ -156,14 +156,14 @@
 * **services**: where the plugin specific service clients are
 
 Additionally, when you're creating the plugin you likely want to follow all
-of the tempest developer and reviewer documentation to ensure that the tests
-being added in the plugin act and behave like the rest of tempest.
+of the Tempest developer and reviewer documentation to ensure that the tests
+being added in the plugin act and behave like the rest of Tempest.
 
 Dealing with configuration options
 ----------------------------------
 
-Historically Tempest didn't provide external guarantees on its configuration
-options. However, with the introduction of the plugin interface this is no
+Historically, Tempest didn't provide external guarantees on its configuration
+options. However, with the introduction of the plugin interface, this is no
 longer the case. An external plugin can rely on using any configuration option
 coming from Tempest, there will be at least a full deprecation cycle for any
 option before it's removed. However, just the options provided by Tempest
@@ -171,7 +171,7 @@
 configuration options you should use the ``register_opts`` and
 ``get_opt_lists`` methods to pass them to Tempest when the plugin is loaded.
 When adding configuration options the ``register_opts`` method gets passed the
-CONF object from tempest. This enables the plugin to add options to both
+CONF object from Tempest. This enables the plugin to add options to both
 existing sections and also create new configuration sections for new options.
 
 Service Clients
@@ -325,23 +325,23 @@
 
 Tempest will automatically discover any installed plugins when it is run. So by
 just installing the python packages which contain your plugin you'll be using
-them with tempest, nothing else is really required.
+them with Tempest, nothing else is really required.
 
 However, you should take care when installing plugins. By their very nature
-there are no guarantees when running tempest with plugins enabled about the
+there are no guarantees when running Tempest with plugins enabled about the
 quality of the plugin. Additionally, while there is no limitation on running
-with multiple plugins it's worth noting that poorly written plugins might not
+with multiple plugins, it's worth noting that poorly written plugins might not
 properly isolate their tests which could cause unexpected cross interactions
 between plugins.
 
 Notes for using plugins with virtualenvs
 ----------------------------------------
 
-When using a tempest inside a virtualenv (like when running under tox) you have
+When using a Tempest inside a virtualenv (like when running under tox) you have
 to ensure that the package that contains your plugin is either installed in the
 venv too or that you have system site-packages enabled. The virtualenv will
-isolate the tempest install from the rest of your system so just installing the
-plugin package on your system and then running tempest inside a venv will not
+isolate the Tempest install from the rest of your system so just installing the
+plugin package on your system and then running Tempest inside a venv will not
 work.
 
 Tempest also exposes a tox job, all-plugin, which will setup a tox virtualenv