fix label warnings (#2417)

* fix broken links

* fix some more label problems

* Apply suggestions from code review

Co-authored-by: Felix Fontein <[email protected]>

---------

Co-authored-by: Felix Fontein <[email protected]>

Author: samccann

docs/docsite/rst/ansible_index.rst

@@ -63,7 +63,6 @@ Contributors develop and change modules and plugins, hosted in collections, much
    :caption: Common Ansible Scenarios
 
    scenario_guides/cloud_guides
-   scenario_guides/network_guides
 
 .. toctree::
    :maxdepth: 2

docs/docsite/rst/community/collection_contributors/collection_requirements.rst

@@ -105,7 +105,7 @@ The following guidelines describe the required infrastructure for your collectio
 Python Compatibility
 ====================
 
-In addition to the Python requirements specified in this section, collections SHOULD adhere to the tips at :ref:`ansible-and-python-3`.
+In addition to the Python requirements specified in this section, collections SHOULD adhere to the tips at :ref:`ansible_and_python_3`.
 
 .. _coll_python_reqs:
 
@@ -227,19 +227,19 @@ Other directories
 .. _coll_docs_structure_reqs:
 
 Documentation requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Collections:
 
-* ``MUST`` use :ref:`links and formatting macros <linking-and-other-format-macros-within-module-documentation>`.
+* ``MUST`` use :ref:`links and formatting macros <module_documents_linking>`.
 * ``SHOULD`` have contributor guidelines in the ``CONTRIBUTING.md`` or ``README.md`` file.
 
 All modules and plugins:
 
-* ``MUST`` include a :ref:`DOCUMENTATION <documentation-block>` block.
-* ``MUST`` include an :ref:`EXAMPLES <examples-block>` block (except where not relevant for the plugin type).
+* ``MUST`` include a :ref:`DOCUMENTATION <documentation_block>` block.
+* ``MUST`` include an :ref:`EXAMPLES <examples_block>` block (except where not relevant for the plugin type).
 * ``MUST`` use FQCNs when referring to modules, plugins and documentation fragments inside and outside the collection including ``ansible.builtin.`` for ansible-core.
-* ``MUST`` include a :ref:`RETURN <return-block>` block for modules and other plugins that return data.
+* ``MUST`` include a :ref:`RETURN <return_block>` block for modules and other plugins that return data.
 * ``MUST`` include the ``version_added`` field when adding new content to an existing collection for entities that support it, for example, for modules, plugins, options, return values, and attributes.
 
   * You do not have to add ``version_added`` when creating a new collection before its first release.
@@ -326,7 +326,7 @@ Module naming
 * Modules that only gather and return information MUST be named ``<something>_info``.
 * Modules that gather and return ``ansible_facts`` MUST be named ``<something>_facts`` and MUST NOT return anything but facts.
 
-For more information, refer to the :ref:`Developing modules guidelines <creating-an-info-or-a-facts-module>`.
+For more information, refer to the :ref:`Developing modules guidelines <creating_info_facts>`.
 
 .. _coll_licensing_req:
 
@@ -427,8 +427,8 @@ To receive important announcements that can affect the collections (for example,
 
   * Collections MUST run an equivalent of the ``ansible-test sanity --docker`` command.
 
-    * If they do not use ``--docker``, they must make sure that all tests run, in particular the compile and import tests (which should run for all :ref:`supported Python versions <ansible-and-python-3>`).
-    * Collections can choose to skip certain Python versions that they explicitly do not support; this needs to be documented in ``README.md`` and in every module and plugin (hint: use a docs fragment). However, we strongly recommend you follow the :ref:`Ansible Python Compatibility <ansible-and-python-3>` section for more details.
+    * If they do not use ``--docker``, they must make sure that all tests run, in particular the compile and import tests (which should run for all :ref:`supported Python versions <ansible_and_python_3>`).
+    * Collections can choose to skip certain Python versions that they explicitly do not support; this needs to be documented in ``README.md`` and in every module and plugin (hint: use a docs fragment). However, we strongly recommend you follow the :ref:`Ansible Python Compatibility <ansible_and_python_3>` section for more details.
 
 * You SHOULD *additionally* run ``ansible-test sanity`` from the ansible/ansible ``devel`` branch so that you find out about new linting requirements earlier.
 * The sanity tests MUST pass.
@@ -493,10 +493,10 @@ Development conventions
 All modules in your collection:
 
 * MUST satisfy all the requirements listed in the :ref:`module_dev_conventions`.
-* MUST satisfy the concept of :ref:`idempotency <term-Idempotency>`: if a module repeatedly runs with the same set of inputs, it will not make any changes on the system.
+* MUST satisfy the concept of :term:`idempotency <Idempotency>`: if a module repeatedly runs with the same set of inputs, it will not make any changes on the system.
 * MUST NOT query information using special ``state`` option values like ``get``, ``list``, ``query``, or ``info`` -
-  create new ``_info`` or ``_facts`` modules instead (for more information, refer to the :ref:`Developing modules guidelines <creating-an-info-or-a-facts-module>`).
-* ``check_mode`` MUST be supported by all ``*_info`` and ``*_facts`` modules (for more information, refer to the :ref:`Development conventions <#following-ansible-conventions>`).
+  create new ``_info`` or ``_facts`` modules instead (for more information, refer to the :ref:`Developing modules guidelines <creating_info_facts>`).
+* ``check_mode`` MUST be supported by all ``*_info`` and ``*_facts`` modules (for more information, refer to the :ref:`Development conventions <developing_modules_best_practices>`).
 
 .. _coll_dependencies:
 

docs/docsite/rst/community/maintainers_guidelines.rst

@@ -70,7 +70,7 @@ See the :ref:`Communication guide <communication_irc>` to learn more about real-
 Community Topics
 ----------------
 
-The Community and the :ref:`Steering Committee <steering_responsibilitie>` asynchronously discuss and vote on the :ref:`community topics<creating_community_topic>` which impact the whole project or its parts including collections and packaging.
+The Community and the :ref:`Steering Committee <steering_responsibilities>` asynchronously discuss and vote on the :ref:`community topics<creating_community_topic>` which impact the whole project or its parts including collections and packaging.
 
 Share your opinion and vote on the topics to help the community make the best decisions.
 

docs/docsite/rst/community/steering/community_steering_committee.rst

@@ -101,7 +101,7 @@ Depending on a topic you want to discuss with the Community and the Committee, a
 * `Ansible Collection Inclusion Checklist <https://github.com/ansible-collections/ansible-inclusion/blob/main/collection_checklist.md>`_.
 * :ref:`removal_from_ansible`.
 
-.. _community_topics_workflow:
+.. _community_topics_sc:
 
 Community topics workflow
 ^^^^^^^^^^^^^^^^^^^^^^^^^

docs/docsite/rst/dev_guide/ansible_index.rst

@@ -37,7 +37,7 @@ Find the task that best describes what you want to do:
       * a :ref:`network module <developing_modules_network>`
       * a :ref:`Windows module <developing_modules_general_windows>`.
       * an :ref:`Amazon module <ansible_collections.amazon.aws.docsite.dev_guide_intro>`.
-      * an :ref:`oVirt/RHV module <https://github.com/oVirt/ovirt-ansible-collection/blob/master/README-developers.md>`.
+      * an `oVirt/RHV module <https://github.com/oVirt/ovirt-ansible-collection/blob/master/README-developers.md>`_.
       * a :ref:`VMware module <ansible_collections.community.vmware.docsite.vmware_ansible_devguide>`.
    * I want to :ref:`write a series of related modules <developing_modules_in_groups>` that integrate Ansible with a new product (for example, a database, cloud provider, network platform, and so on).
 

docs/docsite/rst/dev_guide/core_index.rst

@@ -1,4 +1,4 @@
-.. _developer_guide:
+.. _core_developer_guide:
 
 ***************
 Developer Guide

docs/docsite/rst/dev_guide/developing_modules_general.rst

@@ -50,6 +50,8 @@ To create a new module in an existing collection called ``my_namespace.my_collec
 .. literalinclude:: ../../../../examples/scripts/my_test.py
    :language: python
 
+.. _creating_info_facts:
+
 Creating an info or a facts module
 ==================================
 

docs/docsite/rst/network/user_guide/network_debug_troubleshooting.rst

@@ -261,7 +261,7 @@ Category "Unable to open shell"
 
 **Platforms:** Any
 
-The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a "catch all" message, meaning you need to enable :ref:`logging <a_note_about_logging>` to find the underlying issues.
+The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a "catch all" message, meaning you need to enable :ref:`logging <enable_network_logging>` to find the underlying issues.
 
 
 

docs/docsite/rst/reference_appendices/logging.rst

@@ -1,3 +1,5 @@
+.. _logging:
+
 **********************
 Logging Ansible output
 **********************

docs/docsite/rst/reference_appendices/python_3_support.rst

@@ -1,3 +1,5 @@
+.. _ansible_and_python_3:
+
 ================
 Python 3 Support
 ================