Addressed review comments

Author: JuliaMongo

source/style-guide/style/callouts.txt

@@ -82,8 +82,8 @@ When creating callouts, use the following guidelines:
   distract users. To avoid stacking callouts, group supplemental information
   from callouts into a dedicated section.
 
-- Don't use callouts in tables and option lists, if possible, because
-  callouts reduce the scannability of tables and options lists.
+- If possible, don't use callouts in tables and option lists
+  Callouts reduce the scannability of tables and options lists.
 
 -  Avoid nesting callouts inside tables and other elements.
 
@@ -94,7 +94,7 @@ When creating callouts, use the following guidelines:
 
 -  Avoid stacking callouts of the same type. For example, avoid adding
    one labeled note directly after another labeled note. Instead, use
-   separate paragraphs or an unordered list within a single callout.
+   a single callout that contains separate paragraphs or an unordered list.
 
 The following callouts might appear in existing documentation but are
 deprecated. Don't use these callouts in new content:

source/style-guide/style/glossaries.txt

@@ -20,9 +20,16 @@ Create a glossary to document the following items:
 
 This section provides guidelines for the following items:
 
+- :ref:`glossary-terms`
+- :ref:`glossary-definitions`
+- :ref:`glossary-xrefs`
+- :ref:`glossary-guidelines`
+
 For guidelines about formatting glossary terms that are used in regular
 text, see :ref:`text-formatting`.
 
+.. _glossary-terms:
+
 Glossary Terms
 --------------
 
@@ -58,6 +65,8 @@ slashes, and apostrophes continue a single word.
 
        newspaper
 
+.. _glossary-definitions:
+
 Glossary Definitions
 --------------------
 
@@ -119,6 +128,8 @@ The following table shows examples.
        and protocols that programmers can use to create application
        services by using an open application.
 
+.. _glossary-xrefs:
+
 Cross-References to Glossary Terms
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -168,6 +179,8 @@ glossary:
        To recover by dropping the selected database and re-creating it.
        *Contrast with* copy over.
 
+.. _glossary-guidelines:
+
 Guidelines for a Comprehensive Glossary
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -196,7 +209,7 @@ comprehensive glossary:
    information about third-party terms. A MongoDB glossary should
    contain mainly MongoDB terms. If the user could find the meaning
    outside of a MongoDB document by using a browser search, then we
-   probably don’t need to include it in the glossary. For example,
+   probably don't need to include it in the glossary. For example,
    *Apache*.
 
 -  If a term is specific to one MongoDB service, start the definition

source/style-guide/style/links-and-cross-references.txt

@@ -6,6 +6,12 @@ Links and Cross-References
 
 .. default-domain:: mongodb
 
+.. contents:: On this page
+   :local:
+   :backlinks: none
+   :depth: 2
+   :class: singlecol
+
 Documentation writers use links to direct users to related material
 outside of the current page or section. Links may be:
 
@@ -79,7 +85,6 @@ Minimize Repeated Links
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 - Don't link to the same target multiple times in the same section.
-
   You may link to the same target multiple times on the same page, but
   think carefully about whether it's absolutely necessary. For example,
   if a page is particularly long and contains many sections, then it might

source/style-guide/style/tables.txt

@@ -12,20 +12,27 @@ Tables
    :depth: 2
    :class: singlecol
 
-Text that's difficult to read in paragraph form often becomes clear
-when put into a table. Tables clarify the relationships among
-information, and they're easy to scan. This topic provides the
-guidelines for the following aspects of tables:
-
-Example tables that reflect the guidelines are presented in a separate
-section at the end of this topic.
+Text that's difficult to read in paragraph form often becomes clearer
+when put into a table. Tables are easy to scan. They clarify the
+relationships between portions of information on the page. This topic
+provides the guidelines for the following aspects of tables:
+
+- :ref:`tables-intros`
+- :ref:`tables-titles`
+- :ref:`tables-column-headers`
+- :ref:`tables-text`
+- :ref:`tables-footnotes`
+- :ref:`tables-apis`
+- :ref:`tables-examples`
 
 .. note::
 
    Don't create tables that are overly complex or that scroll
    horizontally. If a table has too much information, try to break it
    up into smaller tables.
 
+.. _tables-intros:
+
 Introductory Text for Tables
 ----------------------------
 
@@ -39,6 +46,8 @@ the table is in a different article or section.
 To introduce a table, use a sentence (not a fragment), and end the
 sentence with a colon.
 
+.. _tables-titles:
+
 Table Titles
 ------------
 
@@ -66,6 +75,8 @@ When creating table titles, use the following guidelines:
 
 - Don't include trademark symbols in table titles.
 
+.. _tables-column-headers:
+
 Column Headers
 --------------
 
@@ -78,6 +89,8 @@ Use the following guidelines for text in column headers:
    otherwise.
 -  Don't end column headers with ellipses or colons.
 
+.. _tables-text:
+
 Table Text
 ----------
 
@@ -101,6 +114,8 @@ Use the following guidelines for text in table cells:
    percent).
 -  Don't use color to differentiate table text.
 
+.. _tables-footnotes:
+
 Table Footnotes
 ---------------
 
@@ -133,6 +148,8 @@ can use footnotes.
       cell. Use a cell-level footnote if the note applies to multiple
       cells in the table.
 
+.. _tables-apis:
+
 Attribute or Parameter Tables in API documents
 ----------------------------------------------
 
@@ -157,6 +174,8 @@ following additional guidelines:
    definition list or itemized list instead of a table.
 -  Avoid putting definition lists in tables.
 
+.. _tables-examples:
+
 Examples
 --------