Use active ("Run the Tests") rather than passive ("Running the Tests")

voice for the headings.

3 files changed, 34 insertions, 34 deletions

diff --git a/docs/tutorials/wiki/authorization.rst b/docs/tutorials/wiki/authorization.rst
index be36cec61..4c9a77759 100644
--- a/docs/tutorials/wiki/authorization.rst
+++ b/docs/tutorials/wiki/authorization.rst
@@ -27,8 +27,8 @@ The source code for this tutorial stage can be browsed via
 `http://github.com/Pylons/pyramid/tree/master/docs/tutorials/wiki/src/authorization/
 <http://github.com/Pylons/pyramid/tree/master/docs/tutorials/wiki/src/authorization/>`_.
 
-Adding Authentication and Authorization Policies
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Add Authentication and Authorization Policies
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 We'll change our package's ``__init__.py`` file to enable an
 ``AuthTktAuthenticationPolicy`` and an ``ACLAuthorizationPolicy`` to enable
@@ -60,8 +60,8 @@ look like so:
    :linenos:
    :language: python
 
-Adding ``security.py``
-~~~~~~~~~~~~~~~~~~~~~~
+Add ``security.py``
+~~~~~~~~~~~~~~~~~~~
 
 Add a ``security.py`` module within your package (in the same
 directory as ``__init__.py``, ``views.py``, etc.) with the following
@@ -82,8 +82,8 @@ user and groups sources. Note that the ``editor`` user is a member of the
 ``group:editors`` group in our dummy group data (the ``GROUPS`` data
 structure).
 
-Giving Our Root Resource an ACL
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Give Our Root Resource an ACL
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 We need to give our root resource object an :term:`ACL`.  This ACL will be
 sufficient to provide enough information to the :app:`Pyramid` security
@@ -119,8 +119,8 @@ Our resulting ``models.py`` file will now look like so:
    :linenos:
    :language: python
 
-Adding Login and Logout Views
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Add Login and Logout Views
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 We'll add a ``login`` view which renders a login form and processes
 the post from the login form, checking credentials.
@@ -157,8 +157,8 @@ login form.  Before being allowed to continue on to the add or edit form, he
 will have to provide credentials that give him permission to add or edit via
 this login form.
 
-Changing Existing Views
-~~~~~~~~~~~~~~~~~~~~~~~
+Change Existing Views
+~~~~~~~~~~~~~~~~~~~~~
 
 Then we need to change each of our ``view_page``, ``edit_page`` and
 ``add_page`` views in ``views.py`` to pass a "logged in" parameter
@@ -184,8 +184,8 @@ template.  For example:
                logged_in = logged_in,
                edit_url = edit_url)
 
-Adding ``permission`` Declarations to our ``view_config`` Decorators
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Add ``permission`` Declarations to our ``view_config`` Decorators
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 To protect each of our views with a particular permission, we need to pass a
 ``permission`` argument to each of our :class:`pyramid.view.view_config`
@@ -216,8 +216,8 @@ decorators.  To do so, within ``views.py``:
   function consults the ``GROUPS`` data structure.  This means
   that the ``editor`` user can add and edit pages.
 
-Adding the ``login.pt`` Template
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Add the ``login.pt`` Template
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Add a ``login.pt`` template to your templates directory.  It's
 referred to within the login view we just added to ``login.py``.
@@ -241,8 +241,8 @@ class="app-welcome align-right">`` div:
       <a href="${request.application_url}/logout">Logout</a>
    </span>
 
-Seeing Our Changes To ``views.py`` and our Templates
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See Our Changes To ``views.py`` and our Templates
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Our ``views.py`` module will look something like this when we're done:
 
@@ -262,8 +262,8 @@ Our ``view.pt`` template will look something like this when we're done:
    :linenos:
    :language: xml
 
-Viewing the Application in a Browser
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+View the Application in a Browser
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 We can finally examine our application in a browser.  The views we'll try are
 as follows:
diff --git a/docs/tutorials/wiki/definingmodels.rst b/docs/tutorials/wiki/definingmodels.rst
index ee9c13ab2..cdf3b6092 100644
--- a/docs/tutorials/wiki/definingmodels.rst
+++ b/docs/tutorials/wiki/definingmodels.rst
@@ -18,8 +18,8 @@ The source code for this tutorial stage can be browsed via
 `http://github.com/Pylons/pyramid/tree/master/docs/tutorials/wiki/src/models/
 <http://github.com/Pylons/pyramid/tree/master/docs/tutorials/wiki/src/models/>`_.
 
-Deleting the Database
----------------------
+Delete the Database
+-------------------
 
 In the next step, we're going to remove the ``MyModel`` Python model
 class from our ``models.py`` file.  Since this class is referred to within
@@ -30,8 +30,8 @@ directory before proceeding any further.  It's always fine to do this as long
 as you don't care about the content of the database; the database itself will
 be recreated as necessary.
 
-Making Edits to ``models.py``
------------------------------
+Edit ``models.py``
+------------------
 
 .. note::
 
@@ -73,8 +73,8 @@ front page) into the Wiki within the ``appmaker``.  This will provide
 :term:`traversal` a :term:`resource tree` to work against when it attempts to
 resolve URLs to resources.
 
-Looking at the Result of Our Edits to ``models.py``
----------------------------------------------------
+Look at the Result of Our Edits to ``models.py``
+------------------------------------------------
 
 The result of all of our edits to ``models.py`` will end up looking
 something like this:
@@ -83,8 +83,8 @@ something like this:
    :linenos:
    :language: python
 
-Viewing the Application in a Browser
-------------------------------------
+View the Application in a Browser
+---------------------------------
 
 We can't.  At this point, our system is in a "non-runnable" state; we'll need
 to change view-related files in the next chapter to be able to start the
diff --git a/docs/tutorials/wiki/tests.rst b/docs/tutorials/wiki/tests.rst
index c03b6b958..941302d67 100644
--- a/docs/tutorials/wiki/tests.rst
+++ b/docs/tutorials/wiki/tests.rst
@@ -6,8 +6,8 @@ We will now add tests for the models and the views and a few functional
 tests in the ``tests.py``.  Tests ensure that an application works, and
 that it continues to work after some changes are made in the future.
 
-Testing the Models
-==================
+Test the Models
+===============
 
 We write tests for the model
 classes and the appmaker.  Changing ``tests.py``, we'll write a separate test
@@ -20,8 +20,8 @@ classes: one for the ``Page`` model named ``PageModelTests``, one for the
 ``Wiki`` model named ``WikiModelTests``, and one for the appmaker named
 ``AppmakerTests``.
 
-Testing the Views
-=================
+Test the Views
+==============
 
 We'll modify our ``tests.py`` file, adding tests for each view function we
 added above.  As a result, we'll *delete* the ``ViewTests`` test in the file,
@@ -38,8 +38,8 @@ tested in the unit tests, like logging in, logging out, checking that
 the ``viewer`` user cannot add or edit pages, but the ``editor`` user
 can, and so on.
 
-Viewing the results of all our edits to ``tests.py``
-====================================================
+View the results of all our edits to ``tests.py``
+=================================================
 
 Once we're done with the ``tests.py`` module, it will look a lot like the
 below:
@@ -48,8 +48,8 @@ below:
    :linenos:
    :language: python
 
-Running the Tests
-=================
+Run the Tests
+=============
 
 We can run these tests by using ``setup.py test`` in the same way we did in
 :ref:`running_tests`.  However, first we must edit our ``setup.py`` to