DOCS-14695-Upgrading language strength with regards to hidden delayed members

Author: ianf-mongodb

source/core/replica-set-delayed-member.txt

@@ -43,7 +43,12 @@ Delayed members:
   members. Always prevent applications from seeing and querying
   delayed members.
 
-- *Do* vote in :term:`elections <election>` for primary, if :rsconf:`members[n].votes` is set to 1.
+- *Do* vote in :term:`elections <election>` for primary, if 
+  :rsconf:`members[n].votes` is set to 1. Ensuring that delayed members 
+  are non-voting by setting :rsconf:`members[n].votes` to 0 can help 
+  improve performance.
+
+.. include:: /includes/important-delayed-replica-set-members.rst
 
 .. include:: /includes/important-delayed-replica-set-members.rst
 

source/includes/important-delayed-replica-set-members.rst

@@ -7,21 +7,28 @@
    Hiding delayed replica set members prevents applications from seeing 
    and querying delayed data without a direct connection to that member.
    Making delayed replica set members non-voting means they will not 
-   count towards acknowledging write operations with read concern 
-   :readconcern:`"majority"`.
+   count towards acknowledging write operations with write concern 
+   :writeconcern:`"majority"`.
 
    If you do not hide delayed members and one or more nodes 
-   becomes unavailable, the replica set has to wait for the delayed 
+   become unavailable, the replica set has to wait for the delayed 
    member and the commit point lags. A lagged commit point can lead to
    performance issues.
 
-   For example:
+   For example, consider a Primary-Secondary-Delayed replica set
+   configuration where the delayed secondary is voting with a 10
+   minute delay.
 
-   - Primary-Secondary-Delayed replica set config where delayed 
-     secondary is voting with 10 mins delay.
-   - With one non-delayed secondary unavailable, the degraded config of
-     Primary-Delayed will have to wait at least 10 minutes for a write 
-     concern with majority to be acknowledged.
-   - The majority commit point will take longer to advance leading to 
-     cache pressure similar to performance issues with a PSA replica 
-     set.
+   With one non-delayed secondary unavailable, the degraded configuration
+   of Primary-Delayed must wait at least 10 minutes to acknowledge a write
+   operation with :writeconcern:`"majority"`.The majority commit point 
+   will take longer to advance, leading to cache pressure similar 
+   performance issues with a
+   :ref:`Primary with a Secondary and an Arbiter<rs-architecture-psa>`
+   (PSA) replica set.
+
+   For more information on the majority commit point, see 
+   :doc:`Causal Consistency and Read and Write Concerns
+   </core/causal-consistency-read-write-concerns>`. For additional 
+   details on resolving performance issues see the
+   :ref:`replica set maintenance tutorial<performance-issues-psa>`.