s/which/that/

Which is usually for descriptive clauses in technical writing, while
that is restrictive. Most of the time we are being being restrictive.

docs/api-stability.rst

@@ -7,7 +7,7 @@ policy.
 What does this policy cover?
 ----------------------------
 
-This policy includes any API or behavior which is documented in this
+This policy includes any API or behavior that is documented in this
 documentation.
 
 What does "stable" mean?
@@ -47,5 +47,5 @@ entirely. In that case, here's how the process will work:
   ``DeprecationWarning``.
 * In ``cryptography X.Y+3`` the feature will be removed or changed.
 
-In short, code which runs without warnings will always continue to work for a
+In short, code that runs without warnings will always continue to work for a
 period of two releases.

docs/contributing.rst

@@ -22,7 +22,7 @@ devastating, ``cryptography`` has a strict code review policy:
 * A committer may *never* merge their own pull request, a second party must
   merge their changes. If multiple people work on a pull request, it must be
   merged by someone who did not work on it.
-* A patch which breaks tests, or introduces regressions by changing or removing
+* A patch that breaks tests, or introduces regressions by changing or removing
   existing tests should not be merged. Tests must always be passing on
   ``master``.
 * If somehow the tests get into a failing state on ``master`` (such as by a
@@ -33,7 +33,7 @@ devastating, ``cryptography`` has a strict code review policy:
   :doc:`/changelog`.
 
 The purpose of these policies is to minimize the chances we merge a change
-which jeopardizes our users' security.
+that jeopardizes our users' security.
 
 If you believe you've identified a security issue in ``cryptography``, please
 follow the directions on the :doc:`security page </security>`.
@@ -58,10 +58,10 @@ and make hard things possible". One of the perils of writing cryptographic code
 is that secure code looks just like insecure code, and its results are almost
 always indistinguishable. As a result ``cryptography`` has, as a design
 philosophy: "make it hard to do insecure things". Here are a few strategies for
-API design which should be both followed, and should inspire other API choices:
+API design that should be both followed, and should inspire other API choices:
 
 If it is necessary to compare a user provided value with a computed value (for
-example, verifying a signature), there should be an API provided which performs
+example, verifying a signature), there should be an API provided that performs
 the verification in a secure way (for example, using a constant time
 comparison), rather than requiring the user to perform the comparison
 themselves.

docs/doing-a-release.rst

@@ -18,7 +18,7 @@ software.
 Performing the release
 ----------------------
 
-The commit which merged the version number bump is now the official release
+The commit that merged the version number bump is now the official release
 commit for this release. You will need to have ``gpg`` installed and a ``gpg``
 key in order to do a release. Once this has happened:
 

docs/fernet.rst

@@ -31,13 +31,13 @@ symmetric (also known as "secret key") authenticated cryptography.
         Generates a fresh fernet key. Keep this some place safe! If you lose it
         you'll no longer be able to decrypt messages; if anyone else gains
         access to it, they'll be able to decrypt all of your messages, and
-        they'll also be able forge arbitrary messages which will be
+        they'll also be able forge arbitrary messages that will be
         authenticated and decrypted.
 
     .. method:: encrypt(plaintext)
 
         :param bytes plaintext: The message you would like to encrypt.
-        :returns bytes: A secure message which cannot be read or altered
+        :returns bytes: A secure message that cannot be read or altered
                         without the key. It is URL-safe base64-encoded. This is
                         referred to as a "Fernet token".
 

docs/hazmat/backends/interfaces.rst

@@ -16,7 +16,7 @@ A specific ``backend`` may provide one or more of these interfaces.
 
 .. class:: CipherBackend
 
-    A backend which provides methods for using ciphers for encryption
+    A backend that provides methods for using ciphers for encryption
     and decryption.
 
     The following backends implement this interface:

docs/hazmat/backends/multibackend.rst

@@ -10,7 +10,7 @@ MultiBackend
     .. versionadded:: 0.2
 
     This class allows you to combine multiple backends into a single backend
-    which offers the combined features of all of its constituents.
+    that offers the combined features of all of its constituents.
 
     .. code-block:: pycon
 

docs/hazmat/primitives/cryptographic-hashes.rst

@@ -56,7 +56,7 @@ Message Digests
         :meth:`finalize` and get an intermediate digest value while we continue
         to call :meth:`update` on the original.
 
-        :return: A new instance of :class:`Hash` which can be updated
+        :return: A new instance of :class:`Hash` that can be updated
             and finalized independently of the original instance.
         :raises cryptography.exceptions.AlreadyFinalized: See :meth:`finalize`
 

docs/hazmat/primitives/hmac.rst

@@ -67,7 +67,7 @@ message.
         :meth:`finalize` and get an intermediate digest value while we continue
         to call :meth:`update` on the original.
 
-        :return: A new instance of :class:`HMAC` which can be updated
+        :return: A new instance of :class:`HMAC` that can be updated
             and finalized independently of the original instance.
         :raises cryptography.exceptions.AlreadyFinalized: See :meth:`finalize`