Backportapalooza 08 04 (#78450)

* fix broken link (#78434)

(cherry picked from commit eb46ab1399ae30c217d2ba3032cc505d12fef354)

* Fix escaped asterisk in code block demonstrating wildcards (#78375)

The code block is rendered verbatim. This currently results in `\*` being shown, which is incorrect (i.e., not parsed as a wildcard pattern).
Removing the superfluous `\` fixes the rendering.
This PR fixes all instances of this issue on that page.

(cherry picked from commit 9bf5da8f75398584ebb54306454e9cc385ccc4f4)

* add example to import a playbook from collection (#78443)

(cherry picked from commit eb462edb1690cd18dbd5dad48688c0525506ab9f)

* docs: Fix control node reference links (#78424)

(cherry picked from commit f5cac6bc5d6dcf8a6acc1b32e8b77452b7be646f)

* Update galaxy_server_list (#78398)

(cherry picked from commit d92f6da592283482e373c519d12afabe954b31f4)

* Improve grammar (#78391)

(cherry picked from commit ddd8b8bfd9e392d2c1ad643bbe2884f931ff6a79)

Co-authored-by: Tom Janson <priv.tom.janson@gmail.com>
Co-authored-by: Sebastian Gumprich <rndmh3ro@users.noreply.github.com>
Co-authored-by: Ian Wienand <iwienand@redhat.com>
Co-authored-by: Tabah Baridule <dulemartins07@gmail.com>
Co-authored-by: Geoffrey van Wyk <geoffrey@vanwyk.biz>

5 files changed, 13 insertions, 14 deletions

diff --git a/docs/docsite/rst/community/contributor_path.rst b/docs/docsite/rst/community/contributor_path.rst
index 699038177b..aced42b31d 100644
--- a/docs/docsite/rst/community/contributor_path.rst
+++ b/docs/docsite/rst/community/contributor_path.rst
@@ -95,7 +95,7 @@ Become a steering committee member
 
   You do NOT have to be a programmer to become a steering committee member.
 
-The `Steering Committee <community_steering_committee>`_ member status reflects the highest level of trust which allows contributors to lead the project through making very important `decisions <https://github.com/ansible-community/community-topics/issues>`_ for the Ansible project. The Committee members are the community leaders who shape the project's future and the future of automation in the IT world in general.
+The :ref:`Steering Committee <community_steering_committee>` member status reflects the highest level of trust which allows contributors to lead the project through making very important `decisions <https://github.com/ansible-community/community-topics/issues>`_ for the Ansible project. The Committee members are the community leaders who shape the project's future and the future of automation in the IT world in general.
 
 To reach the status, as the current Committee members did before getting it, along with the things mentioned in this document, you should:
 
diff --git a/docs/docsite/rst/dev_guide/developing_python_3.rst b/docs/docsite/rst/dev_guide/developing_python_3.rst
index 43221b0342..ecc2106a6b 100644
--- a/docs/docsite/rst/dev_guide/developing_python_3.rst
+++ b/docs/docsite/rst/dev_guide/developing_python_3.rst
@@ -4,7 +4,7 @@
 Ansible and Python 3
 ********************
 
-The ``ansible-core`` code runs Python 3 (for specific versions check `Control Node Requirements <:ref:control-node-requirements>`_.
+The ``ansible-core`` code runs Python 3 (for specific versions check :ref:`Control Node Requirements <control_node_requirements>`
 Contributors to ``ansible-core`` and to Ansible Collections should be aware of the tips in this document so that they can write code
 that will run on the same versions of Python as the rest of Ansible.
 
@@ -25,7 +25,7 @@ However, the three types of code do not use the same string strategy. If you're
 Minimum version of Python 3.x and Python 2.x
 ============================================
 
-See `Control Node Requirements <:ref:control-node-requirements>`_ and `Managed Node Requirements <:ref:managed-node-requirements>`_ for the
+See :ref:`Control Node Requirements <control_node_requirements>` and `Managed Node Requirements <:ref:managed-node-requirements>`_ for the
 specific versions supported.
 
 Your custom modules can support any version of Python (or other languages) you want, but the above are the requirements for the code contributed to the Ansible project.
diff --git a/docs/docsite/rst/shared_snippets/basic_concepts.txt b/docs/docsite/rst/shared_snippets/basic_concepts.txt
index d4154f6eaa..f2648cbf6a 100644
--- a/docs/docsite/rst/shared_snippets/basic_concepts.txt
+++ b/docs/docsite/rst/shared_snippets/basic_concepts.txt
@@ -20,7 +20,7 @@ To learn more about inventory, see :ref:`the Working with Inventory<intro_invent
 
 Playbooks
 =========
-They contain Plays (which are the basic unit of Ansible execution). this is both an 'execution concept' and how we describe the files on which ``ansible-playbook`` operates on.
+They contain Plays (which are the basic unit of Ansible execution). This is both an 'execution concept' and how we describe the files on which ``ansible-playbook`` operates.
 Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`.
 
 Plays
@@ -31,22 +31,22 @@ It basically consists of an implicit loop over the mapped hosts and tasks and de
 
 Roles
 .....
-A limited distribution of reusable ansible content (tasks, handlers, variables, plugins, templates and files) for use inside of a Play.
+A limited distribution of reusable Ansible content (tasks, handlers, variables, plugins, templates and files) for use inside of a Play.
 To use any Role resource, the Role itself must be imported into the Play.
 
 Tasks
 .....
 The definition of an 'action' to be applied to the managed host. Tasks must always be contained in a Play, directly or indirectly (Role, or imported/included task list file).
-You can execute a single task once with an ad hoc command ``ansible`` or ``ansible-console`` (both create a virtual Play).
+You can execute a single task once with an ad hoc command using ``ansible`` or ``ansible-console`` (both create a virtual Play).
 
 Handlers
 ........
-Special form of a Task, that only execute when notified by a previous task which resulted in a 'changed' status.
+A special form of a Task, that only executes when notified by a previous task which resulted in a 'changed' status.
 
 
 Modules
 =======
-The code or binaries that Ansible copies and executes on each managed node (when needed) to accomplish the action defined in each Task.
+The code or binaries that Ansible copies to and executes on each managed node (when needed) to accomplish the action defined in each Task.
 Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device.
 You can invoke a single module with a task, or invoke several different modules in a playbook.
 Ansible modules are grouped in collections. For an idea of how many collections Ansible includes, see the :ref:`list_of_collections`.
@@ -61,7 +61,7 @@ See :ref:`working_with_plugins` for details.
 
 Collections
 ===========
-Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_. To learn more about collections, see :ref:`collections`. Collection resources can be used independently and discretely from each other.
+A format in which Ansible content is distributed that can contain playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_. To learn more about collections, see :ref:`collections`. Collection resources can be used independently and discretely from each other.
 
 
 AAP
diff --git a/docs/docsite/rst/shared_snippets/galaxy_server_list.txt b/docs/docsite/rst/shared_snippets/galaxy_server_list.txt
index be54f1f045..9991d85899 100644
--- a/docs/docsite/rst/shared_snippets/galaxy_server_list.txt
+++ b/docs/docsite/rst/shared_snippets/galaxy_server_list.txt
@@ -75,5 +75,4 @@ For operations that use only one Galaxy server (for example, the ``publish``, ``
 ``server_list``, unless you pass in an explicit server with the ``--server`` argument.
 
 .. note::
-    Once a collection is found, any of its requirements are only searched within the same Galaxy instance as the parent
-    collection. The install process will not search for a collection requirement in a different Galaxy instance.
+    ``ansible-galaxy`` can seek out dependencies on other configured Galaxy instances to support the use case where a collection can depend on a collection from another Galaxy instance.
diff --git a/docs/docsite/rst/user_guide/intro_patterns.rst b/docs/docsite/rst/user_guide/intro_patterns.rst
index 3d0686da50..f4c209912b 100644
--- a/docs/docsite/rst/user_guide/intro_patterns.rst
+++ b/docs/docsite/rst/user_guide/intro_patterns.rst
@@ -82,9 +82,9 @@ You can use wildcard patterns with FQDNs or IP addresses, as long as the hosts a
 
 .. code-block:: yaml
 
-   192.0.\*
-   \*.example.com
-   \*.com
+   192.0.*
+   *.example.com
+   *.com
 
 You can mix wildcard patterns and groups at the same time: