DOCS-12171: Clarify that only data-bearing members vote, hidden and d…

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

@@ -56,6 +56,18 @@ When choosing the amount of delay, consider that the amount of delay:
 - must be *smaller* than the capacity of the oplog. For more
   information on oplog size, see :ref:`replica-set-oplog-sizing`.
 
+Write Concern
+~~~~~~~~~~~~~
+
+Delayed replica set members can acknowledge write operations issued
+with :ref:`write-concern`. Delayed members can also acknowledge
+write operations with ``majority`` write concern *if* they are also
+voting members. Non-voting replica set members cannot contribute to 
+acknowledging write operations with ``majority`` write concern.
+
+Delayed secondaries can return write acknowledgment no earlier than the 
+configured :rsconf:`~members[n].slaveDelay`.
+
 Sharding
 ~~~~~~~~
 

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

@@ -50,12 +50,21 @@ Voting
 
 Hidden members *may* vote in replica set elections. If you stop a
 voting hidden member, ensure that the set has an active majority or the
-:term:`primary` will step down.
+:term:`primary` will step down. 
 
 For the purposes of backups,
 
 - .. include:: /includes/extracts/wt-fsync-lock-compatibility.rst
 
+Write Concern
+~~~~~~~~~~~~~
+
+Hidden replica set members can acknowledge write operations issued
+with :ref:`write-concern`. Hidden members can also acknowledge
+write operations with ``majority`` write concern *if* they are also
+voting members. Non-voting replica set members cannot contribute to 
+acknowledging write operations with ``majority`` write concern.
+
 Further Reading
 ---------------
 

source/core/replica-set-priority-0-member.txt

@@ -14,7 +14,12 @@ Priority 0 Replica Set Members
 
 A :rsconf:`priority 0 <members[n].priority>` member is a member that
 **cannot** become :term:`primary` and **cannot** trigger
-:term:`elections <election>`.
+:term:`elections <election>`. Priority 0 members can acknowledge write 
+operations issued with :ref:`write-concern` of ``w : <number>``.
+Priority 0 members can also acknowledge write operations with 
+``majority`` write concern *if* they are also
+voting members. Non-voting replica set members cannot contribute to 
+acknowledging write operations with ``majority`` write concern.
 
 Other than the aforementioned restrictions, secondaries that have
 :rsconf:`priority 0 <members[n].priority>` function as normal

source/core/replica-set-write-concern.txt

@@ -10,39 +10,83 @@ Write Concern for Replica Sets
    :depth: 1
    :class: singlecol
 
-Write concern describes the level of acknowledgement requested from
-MongoDB for write operations.
+You can use :ref:`write concern <write-concern>` to set the minimum 
+number of data-bearing replica set members that must acknowledge 
+receiving and applying a write operation before returning success. 
+
+For replica sets, the default write concern of ``w: 1`` requires
+that only the primary receive and acknowledge the write. Write 
+operations with write concern ``w`` greater than ``1`` require 
+acknowledgment from the primary and as many data-bearing 
+:doc:`secondaries </core/replica-set-secondary>` as required to meet 
+the requested write concern. Write operations with write concern
+``w : majority`` apply an additional criteria where only voting
+secondaries can acknowledge the write. For complete documentation on 
+member acknowledgment behavior, see 
+:ref:`Replica Set Acknowledgment Behavior <wc-replica-ack-behavior>`.
+
+The following diagram illustrates a write operation issued with a
+write concern of ``w: 2``. The operation blocks until the primary
+and at least one secondary acknowledge the write operation. Secondaries 
+can return write acknowledgment no earlier than after the primary 
+receives, applies, and replicates that write.
+
+.. include:: /images/crud-write-concern-w2.rst
+
+The more data-bearing members that acknowledge a write as successful, 
+the less likely that data will be rolled back if the
+:ref:`primary fails <replication-auto-failover>`. However, the write 
+operation must wait until it receives the requested level of 
+acknowledgment. With higher values of write concern, users trade
+a more reliable promise of data durability for write speed. With
+lower values of write concern, users trade fast writes for the promise
+of data durability.
+
+Selecting the ideal write concern for any given write operation depends
+on your application's performance goals and data durability 
+requirements.
 
 Verify Write Operations to Replica Sets
 ---------------------------------------
 
-For a replica set, the default :doc:`write concern
-</reference/write-concern>` requests acknowledgement only from the primary.
-You can, however, override this default write concern, such as to
-confirm write operations on a specified number of the replica set
-members.
+For write operations that support user-specified write concern, set
+the :ref:`write concern <wc-w>` based on the number of data-bearing
+replica set members you want to acknowledge the write before
+returning success. The exact syntax for specifying write concern
+depends on the write operation. Refer to the documentation for that
+write operation for instructions on syntax and use.
 
-.. include:: /images/crud-write-concern-w2.rst
+For example, the :method:`db.collection.insert()` method
+supports a ``writeConcern`` document as an option. In the following
+operation, the ``writeConcern`` document specifies ``w : 2``, which 
+corresponds to requiring acknowledgment from the primary and at least 
+one data-bearing secondary. This can include hidden or delayed 
+secondaries:
+
+.. code-block:: javascript
+
+   db.products.insert(
+      { item: "envelopes", qty : 100, type: "Clasp" },
+      { writeConcern: { w: 2 } }
+   )
 
-To override the default write concern, specify a write concern with
-each write operation. For example, the following method includes a
-write concern that specifies that the method return only after the
-write propagates to the primary and at least one secondary or the
-method times out after 5 seconds.
+With the specified write concern, the write operation blocks until the 
+primary and at least one secondary acknowledge the write. You can set
+an additional timeout parameter using :ref:`wc-wtimeout`. The following
+operation times out after 5 seconds, returning a write concern error
+on timeout:
 
 .. code-block:: javascript
 
    db.products.insert(
       { item: "envelopes", qty : 100, type: "Clasp" },
-      { writeConcern: { w: 2, wtimeout: 5000 } }
+      { writeConcern: { w: 2 , , wtimeout: 5000 } }
    )
 
-You can include a timeout threshold for a write concern. This prevents
-write operations from blocking indefinitely if the write concern is
-unachievable. For example, if the write concern requires
-acknowledgement from 4 members of the replica set and the replica set
-has only available 3 members, the operation blocks until those members
-become available. See :ref:`wc-wtimeout`.
+A write operation that times out waiting for the specified write concern 
+does not indicate write failure. It only indicates that the ``w`` 
+number of replica set members did not acknowledge the write 
+operation in the ``wtimeout`` time period.
 
 .. seealso::
    :ref:`write-methods-incompatibility`

source/reference/replica-configuration.txt

@@ -261,6 +261,9 @@ Replica Set Configuration Fields
       read operations (i.e. queries) from ever reaching this host by
       way of secondary :term:`read preference`.
 
+      Hidden members can contribute to acknowledging write operations
+      issued with :ref:`write-concern`. 
+
       .. seealso::
          :ref:`Hidden Replica Set Members <replica-set-hidden-members>`
 
@@ -335,6 +338,11 @@ Replica Set Configuration Fields
       of the data that reflects the state of the data at some time in
       the past.
 
+      Delayed members can contribute to acknowledging write
+      operations issued with :ref:`write-concern`. However,
+      they return write acknowledgment no earlier than the configured
+      delay value.
+
       .. seealso::
          :doc:`/core/replica-set-delayed-member`
 
@@ -365,6 +373,9 @@ Replica Set Configuration Fields
 
       .. include:: /includes/members-used-to-allow-multiple-votes.rst
 
+      Members with ``0`` votes cannot acknowledge write operations
+      issued with a :ref:`write-concern` of :writeconcern:`majority`.
+
 ``settings``
 ~~~~~~~~~~~~