diff --git a/docs/ref/clickjacking.txt b/docs/ref/clickjacking.txt
index 0b81243b92..cb3ac1bcd1 100644
--- a/docs/ref/clickjacking.txt
+++ b/docs/ref/clickjacking.txt
@@ -20,7 +20,7 @@ purchase an item. A user has chosen to stay logged into the store all the time
 for convenience. An attacker site might create an "I Like Ponies" button on one
 of their own pages, and load the store's page in a transparent iframe such that
 the "Buy Now" button is invisibly overlaid on the "I Like Ponies" button. If the
-user visits the attacker site and clicks "I Like Ponies" he will inadvertently
+user visits the attacker site and clicks "I Like Ponies" he or she will inadvertently
 click on the online store's "Buy Now" button and unknowingly purchase the item.
 
 .. _clickjacking-prevention:
diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
index fd2e917c1d..225475803f 100644
--- a/docs/ref/contrib/sites.txt
+++ b/docs/ref/contrib/sites.txt
@@ -172,7 +172,7 @@ Getting the current domain for display
 
 LJWorld.com and Lawrence.com both have email alert functionality, which lets
 readers sign up to get notifications when news happens. It's pretty basic: A
-reader signs up on a Web form, and he immediately gets an email saying,
+reader signs up on a Web form, and he or she immediately gets an email saying,
 "Thanks for your subscription."
 
 It'd be inefficient and redundant to implement this signup-processing code
diff --git a/docs/releases/1.4.6.txt b/docs/releases/1.4.6.txt
index 3847ea26f9..e3ccbbb344 100644
--- a/docs/releases/1.4.6.txt
+++ b/docs/releases/1.4.6.txt
@@ -19,7 +19,7 @@ The security checks for these redirects (namely
 ``django.util.http.is_safe_url()``) didn't check if the scheme is ``http(s)``
 and as such allowed ``javascript:...`` URLs to be entered. If a developer
 relied on ``is_safe_url()`` to provide safe redirect targets and put such a
-URL into a link, he could suffer from a XSS attack. This bug doesn't affect
+URL into a link, he or she could suffer from a XSS attack. This bug doesn't affect
 Django currently, since we only put this URL into the ``Location`` response
 header and browsers seem to ignore JavaScript there.
 
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index 0bd1da0ef8..1ba2c6ac7f 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -811,7 +811,7 @@ instance:
 
   * Consequences: The user will see an error about the form having expired
     and will be sent back to the first page of the wizard, losing the data
-    he has entered so far.
+    he or she has entered so far.
 
   * Time period: The amount of time you expect users to take filling out the
     affected forms.
diff --git a/docs/releases/1.5.2.txt b/docs/releases/1.5.2.txt
index 20771365aa..2a2cf9195d 100644
--- a/docs/releases/1.5.2.txt
+++ b/docs/releases/1.5.2.txt
@@ -16,7 +16,7 @@ The security checks for these redirects (namely
 ``django.util.http.is_safe_url()``) didn't check if the scheme is ``http(s)``
 and as such allowed ``javascript:...`` URLs to be entered. If a developer
 relied on ``is_safe_url()`` to provide safe redirect targets and put such a
-URL into a link, he could suffer from a XSS attack. This bug doesn't affect
+URL into a link, he or she could suffer from a XSS attack. This bug doesn't affect
 Django currently, since we only put this URL into the ``Location`` response
 header and browsers seem to ignore JavaScript there.
 
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index b336bf4669..c514978f57 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -166,7 +166,7 @@ and the :setting:`SECRET_KEY` setting.
     cookie backend might open you up to `replay attacks`_. Unlike other session
     backends which keep a server-side record of each session and invalidate it
     when a user logs out, cookie-based sessions are not invalidated when a user
-    logs out. Thus if an attacker steals a user's cookie, he can use that
+    logs out. Thus if an attacker steals a user's cookie, he or she can use that
     cookie to login as that user even if the user logs out. Cookies will only
     be detected as 'stale' if they are older than your
     :setting:`SESSION_COOKIE_AGE`.