diff --git a/source/administration/sharding.txt b/source/administration/sharding.txt
index fb902940383..f381b62019f 100644
--- a/source/administration/sharding.txt
+++ b/source/administration/sharding.txt
@@ -794,7 +794,7 @@ bulk insert operations:
   shards. To avoid this performance cost, you can pre-split the
   collection, as described in :ref:`sharding-administration-pre-splitting`.
 
-- You can parallels import by sending insert operations to more than
+- You can parallel-import by sending insert operations to more than
   one :program:`mongos` instance. If the collection is empty,
   pre-split first, as described in
   :ref:`sharding-administration-pre-splitting`.
@@ -810,7 +810,7 @@ bulk insert operations:
   increasing shard key, then consider the following modifications to
   your application:
 
-  - Reverse all the bits of the shard key to preserves the information
+  - Reverse all the bits of the shard key to preserve the information
     while avoiding the correlation of insertion order and increasing
     sequence of values.
 
@@ -994,8 +994,8 @@ all migration, use the following procedure:
 
 .. note::
 
-   If a migration is in progress progress, the system will complete
-   the in progress migration. After disabling, you can use the
+   If a migration is in progress, the system will complete
+   the in-progress migration. After disabling, you can use the
    following operation in the :program:`mongo` shell to determine if
    there are no migrations in progress:
 
@@ -1233,7 +1233,7 @@ of the cluster metadata from the config database is straight forward:
 
 .. seealso:: :doc:`backups`.
 
-.. [#read-only] While one of the three config servers unavailable, no
+.. [#read-only] While one of the three config servers is unavailable,
    the cluster cannot split any chunks nor can it migrate chunks
    between shards. Your application will be able to write data to the
    cluster. The :ref:`sharding-config-server` section of the
@@ -1291,7 +1291,7 @@ Finally, if your shard key has a low :ref:`cardinality
 <sharding-shard-key-cardinality>`, MongoDB may not be able to create
 sufficient splits among the data.
 
-One Shard Receives too much Traffic
+One Shard Receives Too Much Traffic
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In some situations, a single shard or a subset of the cluster will
@@ -1307,7 +1307,7 @@ In the worst case, you may have to consider re-sharding your data
 and :ref:`choosing a different shard key <sharding-internals-choose-shard-key>`
 to correct this pattern.
 
-The Cluster does not Balance
+The Cluster Does Not Balance
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you have just deployed your sharded cluster, you may want to
@@ -1362,7 +1362,7 @@ consider the following options, depending on the nature of the impact:
      :ref:`add one or two shards <sharding-procedure-add-shard>` to
      the cluster to distribute load.
 
-It's also possible, that your shard key causes your
+It's also possible that your shard key causes your
 application to direct all writes to a single shard. This kind of
 activity pattern can require the balancer to migrate most data soon after writing
 it. Consider redeploying your cluster  with a shard key that provides