diff --git a/doc/source/contributor/api_conditional_updates.rst b/doc/source/contributor/api_conditional_updates.rst
index d240e70f1f1..9714baa454c 100644
--- a/doc/source/contributor/api_conditional_updates.rst
+++ b/doc/source/contributor/api_conditional_updates.rst
@@ -53,7 +53,7 @@ Conditional Update
 
 Conditional Update is the mechanism we use in Cinder to prevent races when
 updating the DB.  In essence it is the SQL equivalent of an ``UPDATE ... FROM
-... WHERE;`` clause
+... WHERE;`` clause.
 
 It is implemented as an abstraction layer on top of SQLAlchemy ORM engine in
 our DB api layer and exposed for consumption in Cinder's Persistent Versioned
@@ -65,7 +65,8 @@ Method signature is:
 .. code:: python
 
    def conditional_update(self, values, expected_values=None, filters=(),
-                          save_all=False, session=None, reflect_changes=True):
+                          save_all=False, session=None, reflect_changes=True,
+                          order=None):
 
 :values:
   Dictionary of key-value pairs with changes that we want to make to the
@@ -97,6 +98,9 @@ Method signature is:
   reflect these changes, but we can prevent this instance update passing False
   on this argument.
 
+:order:
+  Specific order of fields in which to update the values.
+
 :Return Value:
   We'll return the number of changed rows.  So we'll get a 0 value if the
   conditional update has not been successful instead of an exception.
@@ -364,8 +368,8 @@ The idea is simple, using ``Case`` class we can say which values to set in a
 field based on conditions and also set a default value if none of the
 conditions are True.
 
-Conditions must be SQLAlchemy conditions, so we'll need to use fields from the
- ``model`` attribute.
+Conditions must be SQLAlchemy conditions, so we'll need to use fields from
+the ``model`` attribute.
 
 For example setting the status to "maintenance" during migration if current
 status is "available" and leaving it as it was if it's not can be done using
diff --git a/doc/source/contributor/replication.rst b/doc/source/contributor/replication.rst
index f9420bb0d18..7cb4dad2ced 100644
--- a/doc/source/contributor/replication.rst
+++ b/doc/source/contributor/replication.rst
@@ -119,7 +119,7 @@ Capabilities reporting
 ----------------------
 
 There are 2 new replication stats/capability keys that drivers supporting
-relication v2.1 should be reporting: ``replication_enabled`` and
+replication v2.1 should be reporting: ``replication_enabled`` and
 ``replication_targets``::
 
     stats["replication_enabled"] = True|False
@@ -345,7 +345,7 @@ the manager by default, but it won't create additional DB queries if it is
 returned.  It is however necessary to set it to ``FAILOVER_ERROR`` for those
 volumes that had errors during the failover.
 
-Driver's don't have to worry about snapshots or non replicated volumes, since
+Drivers don't have to worry about snapshots or non replicated volumes, since
 the manager will take care of those in the following manner:
 
 - All non replicated volumes will have their current ``status`` field saved in
@@ -377,7 +377,7 @@ Drivers are not required to support failback, but they are required to raise a
 supported.
 
 The way to request the failback is quite simple, the driver will receive the
-argument ``secondary_id`` with the value of ``default``.  That is why if was
+argument ``secondary_id`` with the value of ``default``.  That is why it was
 forbidden to use the ``default`` on the target configuration in the cinder
 configuration file.