diff --git a/doc/source/library/api_microversion_testing.rst b/doc/source/library/api_microversion_testing.rst
index 8be924d..e979683 100644
--- a/doc/source/library/api_microversion_testing.rst
+++ b/doc/source/library/api_microversion_testing.rst
@@ -9,9 +9,9 @@
 
 Many of the OpenStack components have implemented API microversions.
 It is important to test those microversions in Tempest or external plugins.
-Tempest now provides stable interfaces to support to test the API microversions.
+Tempest now provides stable interfaces to support testing the API microversions.
 Based on the microversion range coming from the combination of both configuration
-and each test case, APIs request will be made with selected microversion.
+and each test case, APIs requests will be made with the selected microversion.
 
 This document explains the interfaces needed for microversion testing.
 
diff --git a/doc/source/library/clients.rst b/doc/source/library/clients.rst
index 0f4ba4c..fe9f4ca 100644
--- a/doc/source/library/clients.rst
+++ b/doc/source/library/clients.rst
@@ -6,11 +6,11 @@
 Tests make requests against APIs using service clients. Service clients are
 specializations of the ``RestClient`` class. The service clients that cover the
 APIs exposed by a service should be grouped in a service clients module.
-A service clients module is python module where all service clients are
+A service clients module is a Python module where all service clients are
 defined. If major API versions are available, submodules should be defined,
 one for each version.
 
-The ``ClientsFactory`` class helps initializing all clients of a specific
+The ``ClientsFactory`` class helps to initialize all clients of a specific
 service client module from a set of shared parameters.
 
 The ``ServiceClients`` class provides a convenient way to get access to all
diff --git a/doc/source/library/credential_providers.rst b/doc/source/library/credential_providers.rst
index d25f85c..8c9a16a 100644
--- a/doc/source/library/credential_providers.rst
+++ b/doc/source/library/credential_providers.rst
@@ -4,12 +4,12 @@
 ====================
 
 These library interfaces are used to deal with allocating credentials on demand
-either dynamically by calling keystone to allocate new credentials, or from
+either dynamically by calling Keystone to allocate new credentials, or from
 a list of preprovisioned credentials. These 2 modules are implementations of
 the same abstract credential providers class and can be used interchangeably.
 However, each implementation has some additional parameters that are used to
 influence the behavior of the modules. The API reference at the bottom of this
-doc shows the interface definitions for both modules, however that may be a bit
+doc shows the interface definitions for both modules, however, that may be a bit
 opaque. You can see some examples of how to leverage this interface below.
 
 Initialization Example
@@ -30,7 +30,7 @@
       # If a test requires a new account to work, it can have it via forcing
       # dynamic credentials. A new account will be produced only for that test.
       # In case admin credentials are not available for the account creation,
-      # the test should be skipped else it would fail.
+      # the test should be skipped else it will fail.
       identity_version = identity_version or CONF.identity.auth_version
       if CONF.auth.use_dynamic_credentials or force_tenant_isolation:
           admin_creds = get_configured_admin_credentials(
@@ -81,12 +81,12 @@
 Once you have a credential provider object created the access patterns for
 allocating and removing credentials are the same across both the dynamic
 and preprovisioned credentials. These are defined in the abstract
-CredentialProvider class. At a high level the credentials provider enables
-you to get 3 basic types of credentials at once (per object): a primary, alt,
+CredentialProvider class. At a high level, the credentials provider enables
+you to get 3 basic types of credentials at once (per object): primary, alt,
 and admin. You're also able to allocate a credential by role. These credentials
-are tracked by the provider object and delete must manually be called otherwise
-the created resources will not be deleted (or returned to the pool in the case
-of preprovisioned creds)
+are tracked by the provider object and delete must be called manually,
+otherwise, the created resources will not be deleted (or returned to the pool
+in the case of preprovisioned creds).
 
 Examples
 ''''''''