Doc build warning/broken link clean-a-palooza (#37382)

* Doc build warning/broken link clean-a-palooza, WIP commit 1.

* Fixed broken anchor

* Fixing additional broken links; converting from doc to ref.

* Fix anchor

docs/docsite/rst/dev_guide/developing_api.rst

@@ -1,3 +1,5 @@
+.. _developing_api:
+
 Python API
 ==========
 

docs/docsite/rst/dev_guide/developing_inventory.rst

@@ -1,10 +1,12 @@
+.. _developing_inventory:
+
 Developing Dynamic Inventory Sources
 ====================================
 
 .. contents:: Topics
    :local:
 
-As described in :doc:`../intro_dynamic_inventory`, Ansible can pull inventory information from dynamic sources, including cloud sources. You can also create a new dynamic inventory provider by creating a script or program that can output JSON in the correct format when invoked with the proper arguments. There is no restriction on the language used for creating a dynamic inventory provider.
+As described in :ref:`dynamic_inventory`, Ansible can pull inventory information from dynamic sources, including cloud sources. You can also create a new dynamic inventory provider by creating a script or program that can output JSON in the correct format when invoked with the proper arguments. There is no restriction on the language used for creating a dynamic inventory provider.
 
 .. _inventory_script_conventions:
 

docs/docsite/rst/dev_guide/developing_module_utilities.rst

@@ -1,3 +1,5 @@
+.. _appendix_module_utilities:
+
 Appendix: Module Utilities
 ``````````````````````````
 

docs/docsite/rst/dev_guide/developing_modules.rst

@@ -1,3 +1,5 @@
+.. _developing_modules:
+
 Developing Modules
 ==================
 
@@ -16,7 +18,7 @@ return information to ansible by printing a JSON string to stdout before
 exiting.  They take arguments in one of several ways which we'll go into
 as we work through this tutorial.
 
-See :doc:`../modules` for a list of existing modules.
+See :ref:`all_modules` for a list of existing modules.
 
 Modules can be written in any language and are found in the path specified
 by :envvar:`ANSIBLE_LIBRARY` or the ``--module-path`` command line option or
@@ -31,7 +33,7 @@ develop a module. Ask the following questions:
 
 1. Does a similar module already exist?
 
-There are a lot of existing modules available, you should check out the list of existing modules at :doc:`../modules`
+There are a lot of existing modules available, you should check out the list of existing modules at :ref:`modules`
 
 2. Has someone already worked on a similar Pull Request?
 
@@ -93,7 +95,7 @@ The following topics will discuss how to develop and work with modules:
 
 .. seealso::
 
-   :doc:`../modules`
+   :ref:`all_modules`
        Learn about available modules
    :doc:`developing_plugins`
        Learn about developing plugins

docs/docsite/rst/dev_guide/developing_modules_documenting.rst

@@ -188,7 +188,7 @@ The following fields can be used and are all required unless specified otherwise
 :module:
   The name of the module. This must be the same as the filename, without the ``.py`` extension.
 :short_description:
-  * A short description which is displayed on the :doc:`../list_of_all_modules` page and ``ansible-doc -l``.
+  * A short description which is displayed on the :ref:`all_modules` page and ``ansible-doc -l``.
   * As the short description is displayed by ``ansible-doc -l`` without the category grouping it needs enough detail to explain its purpose without the context of the directory structure in which it lives.
   * Unlike ``description:`` this field should not have a trailing full stop.
 :description:

docs/docsite/rst/dev_guide/developing_modules_general_windows.rst

@@ -1,3 +1,5 @@
+.. _developing_modules_general_windows:
+
 Windows Ansible Module Development Walkthrough
 ==============================================
 

docs/docsite/rst/dev_guide/developing_modules_in_groups.rst

@@ -22,12 +22,12 @@ Although it's tempting to get straight into coding, there are a few things to be
 * For new modules going into Ansible 2.4 we are raising the bar so they must be PEP 8 compliant. See :doc:`testing_pep8` for more information.
 * Starting with Ansible version 2.4, all new modules must support Python 2.6 and Python 3.5+. If this is an issue, please contact us (see the "Speak to us" section later in this document to learn how).
 * All modules shipped with Ansible must be done so under the GPLv3 license. Files under the ``lib/ansible/module_utils/`` directory should be done so under the BSD license.
-* Have a look at the existing modules and how they've been named in the :doc:`../list_of_all_modules`, especially in the same functional area (such as cloud, networking, databases).
+* Have a look at the existing modules and how they've been named in the :ref:`all_modules`, especially in the same functional area (such as cloud, networking, databases).
 * Shared code can be placed into ``lib/ansible/module_utils/``
 * Shared documentation (for example describing common arguments) can be placed in ``lib/ansible/utils/module_docs_fragments/``.
 * With great power comes great responsibility: Ansible module maintainers have a duty to help keep modules up to date. As with all successful community projects, module maintainers should keep a watchful eye for reported issues and contributions.
 * Although not required, unit and/or integration tests are strongly recommended. Unit tests are especially valuable when external resources (such as cloud or network devices) are required. For more information see :doc:`testing` and the `Testing Working Group <https://github.com/ansible/community/blob/master/meetings/README.md>`_.
-  * Starting with Ansible 2.4 all :doc:`../list_of_network_modules` MUST have unit tests.
+  * Starting with Ansible 2.4 all :ref:`network_modules` MUST have unit tests.
 
 
 Naming Convention
@@ -37,7 +37,7 @@ As you may have noticed when looking under ``lib/ansible/modules/`` we support u
 
 The directory name should represent the *product* or *OS* name, not the company name.
 
-Each module should have the above (or similar) prefix; see existing :doc:`../list_of_all_modules` for existing examples.
+Each module should have the above (or similar) prefix; see existing :ref:`all_modules` for existing examples.
 
 **Note:**
 
@@ -61,7 +61,7 @@ Where to get support
 
 Ansible has a thriving and knowledgeable community of module developers that is a great resource for getting your questions answered.
 
-On :doc:`../community` you can find how to:
+In the :ref:`ansible_community_guide` you can find how to:
 
 * Subscribe to the Mailing Lists - We suggest "Ansible Development List" (for codefreeze info) and "Ansible Announce list"
 * ``#ansible-devel`` - We have found that IRC ``#ansible-devel`` on FreeNode's IRC network works best for module developers so we can have an interactive dialogue.
@@ -93,7 +93,7 @@ And that's it.
 
 Before pushing your PR to GitHub it's a good idea to review the :doc:`developing_modules_checklist` again.
 
-After publishing your PR to https://github.com/ansible/ansible, a Shippable CI test should run within a few minutes. Check the results (at the end of the PR page) to ensure that it's passing (green). If it's not passing, inspect each of the results. Most of the errors should be self-explanatory and are often related to badly formatted documentation (see :doc:`../YAMLSyntax`) or code that isn't valid Python 2.6  or valid Python 3.5 (see :doc:`developing_python3`). If you aren't sure what a Shippable test message means, copy it into the PR along with a comment and we will review.
+After publishing your PR to https://github.com/ansible/ansible, a Shippable CI test should run within a few minutes. Check the results (at the end of the PR page) to ensure that it's passing (green). If it's not passing, inspect each of the results. Most of the errors should be self-explanatory and are often related to badly formatted documentation (see :ref:`yaml_syntax`) or code that isn't valid Python 2.6  or valid Python 3.5 (see :ref:`developing_python_3`). If you aren't sure what a Shippable test message means, copy it into the PR along with a comment and we will review.
 
 If you need further advice, consider join the ``#ansible-devel`` IRC channel (see how in the "Where to get support").
 

docs/docsite/rst/dev_guide/developing_plugins.rst

@@ -1,3 +1,5 @@
+.. _developing_plugins:
+
 Developing Plugins
 ==================
 
@@ -149,7 +151,7 @@ Connection plugins allow Ansible to connect to the target hosts so it can execut
 
 By default, Ansible ships with several plugins. The most commonly used are the 'paramiko' SSH, native ssh (just called 'ssh'), and 'local' connection types.  All of these can be used in playbooks and with /usr/bin/ansible to decide how you want to talk to remote machines.  
 
-The basics of these connection types are covered in the :doc:`../intro_getting_started` section.  
+The basics of these connection types are covered in the :ref:`intro_getting_started` section.  
 
 Should you want to extend Ansible to support other transports (SNMP, Message bus, etc) it's as simple as copying the format of one of the existing modules and dropping it into the connection plugins directory.  
 
@@ -362,8 +364,8 @@ When shipped as part of a role, the plugin will be available as soon as the role
 
 .. seealso::
 
-   :doc:`../modules`
-       List of built-in modules
+   :ref:`all_modules`
+       List of all modules
    :doc:`developing_api`
        Learn about the Python API for task execution
    :doc:`developing_inventory`

docs/docsite/rst/dev_guide/developing_program_flow_modules.rst

@@ -211,7 +211,7 @@ the managed machine.
   complications around Windows modules that must have the same names as Python
   modules, so that internal calling of modules from other Action Plugins work.)
 
-Much of this functionality comes from the :class:`BaseAction` class,
+Much of this functionality comes from the `BaseAction` class,
 which lives in :file:`plugins/action/__init__.py`.  It makes use of
 ``Connection`` and ``Shell`` objects to do its work.
 
@@ -278,18 +278,18 @@ substitutions:
   - :code:`"<<ANSIBLE_VERSION>>"` is substituted with the Ansible version.  In
     :ref:`new-style Python modules <flow_python_modules>` under the
     :ref:`Ansiballz` framework the proper way is to instead instantiate an
-    :class:`AnsibleModule` and then access the version from
+    `AnsibleModule` and then access the version from
     :attr:``AnsibleModule.ansible_version``.
   - :code:`"<<INCLUDE_ANSIBLE_MODULE_COMPLEX_ARGS>>"` is substituted with
     a string which is the Python ``repr`` of the :term:`JSON` encoded module
     parameters.  Using ``repr`` on the JSON string makes it safe to embed in
     a Python file.  In new-style Python modules under the Ansiballz framework
-    this is better accessed by instantiating an :class:`AnsibleModule` and
+    this is better accessed by instantiating an `AnsibleModule` and
     then using :attr:`AnsibleModule.params`.
   - :code:`<<SELINUX_SPECIAL_FILESYSTEMS>>` substitutes a string which is
     a comma separated list of file systems which have a file system dependent
     security context in SELinux.  In new-style Python modules, if you really
-    need this you should instantiate an :class:`AnsibleModule` and then use
+    need this you should instantiate an `AnsibleModule` and then use
     :attr:`AnsibleModule._selinux_special_fs`.  The variable has also changed
     from a comma separated string of file system names to an actual python
     list of filesystem names.
@@ -302,7 +302,7 @@ substitutions:
     ``syslog_facility`` which was named in :file:`ansible.cfg` or any
     ``ansible_syslog_facility`` inventory variable that applies to this host.  In
     new-style Python modules this has changed slightly.  If you really need to
-    access it, you should instantiate an :class:`AnsibleModule` and then use
+    access it, you should instantiate an `AnsibleModule` and then use
     :attr:`AnsibleModule._syslog_facility` to access it.  It is no longer the
     actual syslog facility and is now the name of the syslog facility.  See
     the :ref:`documentation on internal arguments <flow_internal_arguments>`
@@ -365,7 +365,7 @@ it parses this string and places the args into
 other code.
 
 .. note::
-    Internally, the :class:`AnsibleModule` uses the helper function,
+    Internally, the `AnsibleModule` uses the helper function,
     :py:func:`ansible.module_utils.basic._load_params`, to load the parameters
     from stdin and save them into an internal global variable.  Very dynamic
     custom modules which need to parse the parameters prior to instantiating
@@ -395,7 +395,7 @@ This is a boolean.  If it's True then the playbook specified ``no_log`` (in
 a task's parameters or as a play parameter).  This automatically affects calls
 to :py:meth:`AnsibleModule.log`.  If a module implements its own logging then
 it needs to check this value.  The best way to look at this is for the module
-to instantiate an :class:`AnsibleModule` and then check the value of
+to instantiate an `AnsibleModule` and then check the value of
 :attr:`AnsibleModule.no_log`.
 
 .. note::
@@ -410,7 +410,7 @@ the messages are only logged if this is True.  This also turns on logging of
 external commands that the module executes.  This can be changed via
 the ``debug`` setting in :file:`ansible.cfg` or the environment variable
 :envvar:`ANSIBLE_DEBUG`.  If, for some reason, a module must access this, it
-should do so by instantiating an :class:`AnsibleModule` and accessing
+should do so by instantiating an `AnsibleModule` and accessing
 :attr:`AnsibleModule._debug`.
 
 _ansible_diff
@@ -419,7 +419,7 @@ _ansible_diff
 This boolean is turned on via the ``--diff`` command line option.  If a module
 supports it, it will tell the module to show a unified diff of changes to be
 made to templated files.  The proper way for a module to access this is by
-instantiating an :class:`AnsibleModule` and accessing
+instantiating an `AnsibleModule` and accessing
 :attr:`AnsibleModule._diff`.
 
 _ansible_verbosity
@@ -432,7 +432,7 @@ _ansible_selinux_special_fs
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This is a list of names of filesystems which should have a special selinux
-context.  They are used by the :class:`AnsibleModule` methods which operate on
+context.  They are used by the `AnsibleModule` methods which operate on
 files (changing attributes, moving, and copying).  The list of names is set
 via a comma separated string of filesystem names from :file:`ansible.cfg`::
 
@@ -458,7 +458,7 @@ This parameter controls which syslog facility ansible module logs to.  It may
 be set by changing the ``syslog_facility`` value in :file:`ansible.cfg`.  Most
 modules should just use :meth:`AnsibleModule.log` which will then make use of
 this.  If a module has to use this on its own, it should instantiate an
-:class:`AnsibleModule` and then retrieve the name of the syslog facility from
+`AnsibleModule` and then retrieve the name of the syslog facility from
 :attr:`AnsibleModule._syslog_facility`.  The code will look slightly different
 than it did under :ref:`module_replacer` due to how hacky the old way was
 
@@ -480,7 +480,7 @@ _ansible_version
 ~~~~~~~~~~~~~~~~
 
 This parameter passes the version of ansible that runs the module.  To access
-it, a module should instantiate an :class:`AnsibleModule` and then retrieve it
+it, a module should instantiate an `AnsibleModule` and then retrieve it
 from :attr:`AnsibleModule.ansible_version`.  This replaces
 :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` from
 :ref:`module_replacer`.

docs/docsite/rst/dev_guide/developing_python3.rst

@@ -1,3 +1,5 @@
+.. _developing_python_3:
+
 ====================
 Ansible and Python 3
 ====================

docs/docsite/rst/dev_guide/index.rst

@@ -24,6 +24,6 @@ To get started, select one of the following topics.
    developing_rebasing
    testing
    repomerge
-   ../release_and_maintenance
-   ../committer_guidelines
+   ../reference_appendices/release_and_maintenance
+   ../community/committer_guidelines
    ./style_guide/index

docs/docsite/rst/dev_guide/testing/compile/index.rst

@@ -1,4 +0,0 @@
-Compile Tests
-=============
-
-See :doc:`../../testing_compile` for more information.

docs/docsite/rst/dev_guide/testing_sanity.rst

@@ -73,3 +73,5 @@ yamllint
 ~~~~~~~~
 
 Check YAML files for syntax and formatting issues.
+
+