Merge branch 'master' into 1.3-branch

4 files changed, 8 insertions, 8 deletions

diff --git a/docs/api/security.rst b/docs/api/security.rst
index 7086690e9..814b68e5a 100644
--- a/docs/api/security.rst
+++ b/docs/api/security.rst
@@ -72,13 +72,13 @@ Return Values
 
     The ACE "action" (the first element in an ACE e.g. ``(Allow, Everyone,
     'read')`` that means allow access.  A sequence of ACEs makes up an
-    ACL.  It is a string, and it's actual value is "Allow".
+    ACL.  It is a string, and its actual value is "Allow".
 
 .. attribute:: Deny
 
     The ACE "action" (the first element in an ACE e.g. ``(Deny,
     'george', 'read')`` that means deny access.  A sequence of ACEs
-    makes up an ACL.  It is a string, and it's actual value is "Deny".
+    makes up an ACL.  It is a string, and its actual value is "Deny".
 
 .. autoclass:: ACLDenied
    :members:
diff --git a/docs/designdefense.rst b/docs/designdefense.rst
index 84b6be907..bbcf9c2ec 100644
--- a/docs/designdefense.rst
+++ b/docs/designdefense.rst
@@ -1386,7 +1386,7 @@ predictability.
   actually the best-case circumstance for double-imports; if a module only
   mutates itself and its contents at import time, if it is imported twice,
   that's OK, because each decorator invocation will always be mutating an
-  independent copy of the object its attached to, not a shared resource like
+  independent copy of the object it's attached to, not a shared resource like
   a registry in another module.  This has the effect that
   double-registrations will never be performed.
 
@@ -1727,7 +1727,7 @@ reads something like this:
 
 (Paraphrased from a real email, actually.)
 
-Let's take this criticism point-by point.
+Let's take this criticism point-by-point.
 
 Too Complex
 +++++++++++
diff --git a/docs/narr/testing.rst b/docs/narr/testing.rst
index 7ee432fa7..5ce2c8a66 100644
--- a/docs/narr/testing.rst
+++ b/docs/narr/testing.rst
@@ -303,12 +303,12 @@ In :app:`Pyramid`, a *unit test* typically relies on "mock" or "dummy"
 implementations to give the code under test only enough context to run.
 
 "Integration testing" implies another sort of testing.  In the context of a
-:app:`Pyramid`, integration test, the test logic tests the functionality of
+:app:`Pyramid` integration test, the test logic tests the functionality of
 some code *and* its integration with the rest of the :app:`Pyramid`
 framework.
 
 In :app:`Pyramid` applications that are plugins to Pyramid, you can create an
-integration test by including it's ``includeme`` function via
+integration test by including its ``includeme`` function via
 :meth:`pyramid.config.Configurator.include` in the test's setup code.  This
 causes the entire :app:`Pyramid` environment to be set up and torn down as if
 your application was running "for real".  This is a heavy-hammer way of
@@ -372,7 +372,7 @@ Creating Functional Tests
 Functional tests test your literal application.
 
 The below test assumes that your application's package name is ``myapp``, and
-that there is view that returns an HTML body when the root URL is invoked.
+that there is a view that returns an HTML body when the root URL is invoked.
 It further assumes that you've added a ``tests_require`` dependency on the
 ``WebTest`` package within your ``setup.py`` file.  :term:`WebTest` is a
 functional testing package written by Ian Bicking.
diff --git a/docs/narr/viewconfig.rst b/docs/narr/viewconfig.rst
index 763c0e131..23b4fde68 100644
--- a/docs/narr/viewconfig.rst
+++ b/docs/narr/viewconfig.rst
@@ -900,7 +900,7 @@ When a non-``None`` ``http_cache`` argument is passed to a view
 configuration, Pyramid will set ``Expires`` and ``Cache-Control`` response
 headers in the resulting response, causing browsers to cache the response
 data for some time.  See ``http_cache`` in :ref:`nonpredicate_view_args` for
-the its allowable values and what they mean.
+the allowable values and what they mean.
 
 Sometimes it's undesirable to have these headers set as the result of
 returning a response from a view, even though you'd like to decorate the view