[docs][backport]Backportapalooza 10 (#71621)

* Feature freeze date has been merged with Ansible-2.10.0beta1 (#71494)

(cherry picked from commit c586d43)

* Add --allow-disabled to sanity docs (#71524)

(cherry picked from commit bc64614)

* Update intro_patterns.rst (#71542)

Call out the trailing comma when specifying a single host. Small snag that took me a while to notice.

(cherry picked from commit ec3920c)

* ansible-vault: Fix typo in help message (#71485)

(cherry picked from commit 215eb73)

* update install for 2.10 (#71543)

* update install for 2.10

(cherry picked from commit f75223d)

* User guide overhaul, Table of Contents (#71553)

(cherry picked from commit b694dba)

* update backport instructions for 2.11 (#71567)

* update backport instructions in docs/docsite/rst/community/development_process.rst

Co-authored-by: Matt Martz <matt@sivel.net>
(cherry picked from commit 7f9258b)

* More docs updates to reflect collections ecosystem (#71597)

(cherry picked from commit 96aee76)

* DOCS: Mentions ansible-base, adds collections pointers to Community and Dev Guides (#71480)

(cherry picked from commit 29b20bd)

Co-authored-by: Toshio Kuratomi <a.badger@gmail.com>
Co-authored-by: Amin Vakil <info@aminvakil.com>
Co-authored-by: Matt Deacalion <matt@dirtymonkey.co.uk>
Co-authored-by: Fabien Malfoy <fabien.malfoy@laposte.net>
Co-authored-by: Alicia Cozine <879121+acozine@users.noreply.github.com>

docs/docsite/rst/community/development_process.rst

@@ -4,15 +4,19 @@
 The Ansible Development Cycle
 *****************************
 
-The Ansible development cycle happens on two levels. At a macro level, the team plans releases and tracks progress with roadmaps and projects. At a micro level, each PR has its own lifecycle.
+Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. The `ansible/ansible repository <https://github.com/ansible/ansible>`_ contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-base``. Other repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections.
+
+Development on ``ansible-base`` occurs on two levels. At the macro level, the ``ansible-base`` developers and maintainers plan releases and track progress with roadmaps and projects. At the micro level, each PR has its own lifecycle.
+
+Development on collections also occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-base``.
 
 .. contents::
    :local:
 
-Macro development: roadmaps, releases, and projects
-===================================================
+Macro development: ``ansible-base`` roadmaps, releases, and projects
+=====================================================================
 
-If you want to follow the conversation about what features will be added to Ansible for upcoming releases and what bugs are being fixed, you can watch these resources:
+If you want to follow the conversation about what features will be added to ``ansible-base`` for upcoming releases and what bugs are being fixed, you can watch these resources:
 
 * the :ref:`roadmaps`
 * the :ref:`Ansible Release Schedule <release_and_maintenance>`
@@ -27,7 +31,7 @@ If you want to follow the conversation about what features will be added to Ansi
 Micro development: the lifecycle of a PR
 ========================================
 
-Ansible accepts code through **pull requests** ("PRs" for short). GitHub provides a great overview of `how the pull request process works <https://help.github.com/articles/about-pull-requests/>`_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ansible-base.
+If you want to contribute a feature or fix a bug in ``ansible-base`` or in a collection, you must open a **pull request** ("PR" for short). GitHub provides a great overview of `how the pull request process works <https://help.github.com/articles/about-pull-requests/>`_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ``ansible-base``.
 Here's an overview of the PR lifecycle:
 
 * Contributor opens a PR
@@ -132,7 +136,7 @@ Once a human applies the ``shipit`` label, the :ref:`committers <community_commi
 Making your PR merge-worthy
 ===========================
 
-We don't merge every PR. Here are some tips for making your PR useful, attractive, and merge-worthy.
+We do not merge every PR. Here are some tips for making your PR useful, attractive, and merge-worthy.
 
 .. _community_changelogs:
 
@@ -202,24 +206,24 @@ Here are some examples:
       remote_src=True even if mode was not set as a parameter.  This failed on
       filesystems which do not have permission bits (https://github.com/ansible/ansible/issues/29444).
 
-You can find more example changelog fragments in the `changelog directory <https://github.com/ansible/ansible/tree/stable-2.9/changelogs/fragments>`_ for the 2.9 release.
+You can find more example changelog fragments in the `changelog directory <https://github.com/ansible/ansible/tree/stable-2.10/changelogs/fragments>`_ for the 2.10 release.
 
-Once you've written the changelog fragment for your PR, commit the file and include it with the pull request.
+After you have written the changelog fragment for your PR, commit the file and include it with the pull request.
 
 .. _backport_process:
 
-Backporting merged PRs
-======================
+Backporting merged PRs in ``ansible-base``
+===========================================
 
-All Ansible PRs must be merged to the ``devel`` branch first. After a pull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a previous stable branch.
+All ``ansible-base`` PRs must be merged to the ``devel`` branch first. After a pull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a previous stable branch.
 
 We do **not** backport features.
 
 .. note::
 
    These instructions assume that:
 
-    * ``stable-2.9`` is the targeted release branch for the backport
+    * ``stable-2.10`` is the targeted release branch for the backport
     * ``https://github.com/ansible/ansible.git`` is configured as a
       ``git remote`` named ``upstream``. If you do not use
       a ``git remote`` named ``upstream``, adjust the instructions accordingly.
@@ -232,7 +236,7 @@ We do **not** backport features.
    ::
 
        git fetch upstream
-       git checkout -b backport/2.9/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.9
+       git checkout -b backport/2.10/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.10
 
 #. Cherry pick the relevant commit SHA from the devel branch into your feature
    branch, handling merge conflicts as necessary:
@@ -247,18 +251,18 @@ We do **not** backport features.
 
    ::
 
-       git push origin backport/2.9/[PR_NUMBER_FROM_DEVEL]
+       git push origin backport/2.10/[PR_NUMBER_FROM_DEVEL]
 
-#. Submit the pull request for ``backport/2.9/[PR_NUMBER_FROM_DEVEL]``
-   against the ``stable-2.9`` branch
+#. Submit the pull request for ``backport/2.10/[PR_NUMBER_FROM_DEVEL]``
+   against the ``stable-2.10`` branch
 
 #. The Release Manager will decide whether to merge the backport PR before
    the next minor release. There isn't any need to follow up. Just ensure that the automated
    tests (CI) are green.
 
 .. note::
 
-    The choice to use ``backport/2.9/[PR_NUMBER_FROM_DEVEL]`` as the
+    The choice to use ``backport/2.10/[PR_NUMBER_FROM_DEVEL]`` as the
     name for the feature branch is somewhat arbitrary, but conveys meaning
     about the purpose of that branch. It is not required to use this format,
     but it can be helpful, especially when making multiple backport PRs for

docs/docsite/rst/community/documentation_contributions.rst

@@ -6,7 +6,7 @@ Contributing to the Ansible Documentation
 
 Ansible has a lot of documentation and a small team of writers. Community support helps us keep up with new features, fixes, and changes.
 
-Improving the documentation is an easy way to make your first contribution to the Ansible project. You don't have to be a programmer, since most of our documentation is written in YAML (module documentation) or `reStructuredText <http://docutils.sourceforge.net/rst.html>`_ (rST). Some collection-level documentation is written in a subset of `Markdown <https://github.com/ansible/ansible/issues/68119#issuecomment-596723053>`_. If you're using Ansible, you already use YAML in your playbooks. rST and Markdown are mostly just text. You don't even need git experience, if you use the ``Edit on GitHub`` option.
+Improving the documentation is an easy way to make your first contribution to the Ansible project. You do not have to be a programmer, since most of our documentation is written in YAML (module documentation) or `reStructuredText <http://docutils.sourceforge.net/rst.html>`_ (rST). Some collection-level documentation is written in a subset of `Markdown <https://github.com/ansible/ansible/issues/68119#issuecomment-596723053>`_. If you are using Ansible, you already use YAML in your playbooks. rST and Markdown are mostly just text. You do not even need git experience, if you use the ``Edit on GitHub`` option.
 
 If you find a typo, a broken example, a missing topic, or any other error or omission on this documentation website, let us know. Here are some ways to support Ansible documentation:
 
@@ -47,7 +47,7 @@ You can also contribute by reviewing open documentation `issues <https://github.
 Opening a new issue and/or PR
 =============================
 
-If the problem you've noticed is too complex to fix with the ``Edit on GitHub`` option, and no open issue or PR already documents the problem, please open an issue and/or a PR on the ``ansible/ansible`` repo. If the documentation page has no ``Edit on GitHub`` option, check if the page is for a module within a collection. If so, follow the link to the collection on Galaxy and select the ``repo`` button in the upper right corner to find the source repository for that collection and module. The Collection README file should contain information on how to contribute to that collection, or report issues.
+If the problem you have noticed is too complex to fix with the ``Edit on GitHub`` option, and no open issue or PR already documents the problem, please open an issue and/or a PR on the correct underlying repo - ``ansible/ansible`` for most pages that are not plugin or module documentation. If the documentation page has no ``Edit on GitHub`` option, check if the page is for a module within a collection. If so, follow the link to the collection on Galaxy and select the ``repo`` button in the upper right corner to find the source repository for that collection and module. The Collection README file should contain information on how to contribute to that collection, or report issues.
 
 A great documentation GitHub issue or PR includes:
 
@@ -206,7 +206,7 @@ Unfortunately, leftover rST-files from previous document-generating can occasion
 Joining the documentation working group
 =======================================
 
-The Documentation Working Group is just getting started, please visit the `community repo <https://github.com/ansible/community>`_ for more information.
+The Documentation Working Group (DaWGs) meets weekly on Tuesdays on the #ansible-docs channel on freenode IRC. For more information, including links to our agenda and a calendar invite, please visit the `working group page in the community repo <https://github.com/ansible/community/wiki/Docs>`_.
 
 .. seealso::
    :ref:`More about testing module documentation <testing_module_documentation>`

docs/docsite/rst/community/how_can_I_help.rst

@@ -43,7 +43,7 @@ Participate in your local meetup
 
 There are Ansible meetups `all over the world <https://www.meetup.com/topics/ansible/>`_. Join your local meetup. Attend regularly. Ask good questions. Volunteer to give a presentation about how you use Ansible.
 
-If there isn't a meetup near you, we'll be happy to help you `start one <https://www.ansible.com/community/events/ansible-meetups>`_.
+If there is no meetup near you, we are happy to help you `start one <https://www.ansible.com/community/events/ansible-meetups>`_.
 
 File and verify issues
 ======================
@@ -58,14 +58,14 @@ Review and submit pull requests
 
 As you become more familiar with how Ansible works, you may be able to fix issues or develop new features yourself. If you think you have a fix for a bug in Ansible, or if you have a new feature that you would like to share with millions of Ansible users, read all about the :ref:`Ansible development process <community_development_process>` and and :ref:`how to contribute to collections <contributing_maintained_collections>` to learn how to get your code accepted into Ansible.
 
-Another good way to help is to review pull requests that other Ansible users have submitted. The Ansible community keeps a full list of `open pull requests by file <https://ansible.sivel.net/pr/byfile.html>`_, so if there's a particular module or plug-in that particularly interests you, you can easily keep track of all the relevant new pull requests and provide testing or feedback.
+Another good way to help is to review pull requests that other Ansible users have submitted. The Ansible community keeps a full list of `open pull requests by file <https://ansible.sivel.net/pr/byfile.html>`_, so if a particular module or plugin interests you, you can easily keep track of all the relevant new pull requests and provide testing or feedback.
 
 Become a collection maintainer
 ==============================
 
 Once you have learned about the development process and have contributed code to a collection, we encourage you to become a maintainer of that collection. There are hundreds of modules in dozens of Ansible collections, and the vast majority of them are written and maintained entirely by members of the Ansible community.
 
-To learn more about the responsibilities of being an Ansible module maintainer, please read our :ref:`module maintainer guidelines <maintainers>`.
+To learn more about the responsibilities of being an Ansible module maintainer, please read our :ref:`collection maintainer guidelines <maintainers>`.
 
 .. _community_working_groups:
 

docs/docsite/rst/community/index.rst

@@ -8,7 +8,7 @@ Welcome to the Ansible Community Guide!
 
 The purpose of this guide is to teach you everything you need to know about being a contributing member of the Ansible community. All types of contributions are welcome and necessary to Ansible's continued success.
 
-This page outlines the most common situations and questions that bring readers to this section. If you prefer a traditional table of contents, there's one at the bottom of the page.
+This page outlines the most common situations and questions that bring readers to this section. If you prefer a :ref:`traditional table of contents <community_toc>`, you can find one at the bottom of the page.
 
 
 Getting started
@@ -34,7 +34,7 @@ Going deeper
 ============
 
 * I think Ansible is broken. How do I :ref:`report a bug <reporting_bugs>`?
-* I need functionality that Ansible doesn't offer. How do I :ref:`request a feature <request_features>`?
+* I need functionality that Ansible does not offer. How do I :ref:`request a feature <request_features>`?
 * How do I :ref:`contribute to an Ansible-maintained collection <contributing_maintained_collections>`?
 * I am waiting for a particular feature. How do I see what is :ref:`planned for future Ansible Releases <roadmaps>`?
 * I have a specific Ansible interest or expertise (for example, VMware, Linode, and so on.). How do I get involved in a :ref:`working group <working_group_list>`?
@@ -45,9 +45,9 @@ Going deeper
 Working with the Ansible repo
 =============================
 
-* I want to code my first changes to Ansible. How do I :ref:`set up my Python development environment <environment_setup>`?
+* I want to make my first code changes to a collection or to ``ansible-base``. How do I :ref:`set up my Python development environment <environment_setup>`?
 * I would like to get more efficient as a developer. How can I find :ref:`editors, linters, and other tools <other_tools_and_programs>` that will support my Ansible development efforts?
-* I want my PR to meet Ansible's guidelines. Where can I find  guidance on :ref:`coding in Ansible <developer_guide>`?
+* I want my code to meet Ansible's guidelines. Where can I find  guidance on :ref:`coding in Ansible <developer_guide>`?
 * I want to learn more about Ansible roadmaps, releases, and projects. How do I find information on :ref:`the development cycle <community_development_process>`?
 * I would like to connect Ansible to a new API or other resource. How do I :ref:`create a collection <developing_modules_in_groups>`?
 * My pull request is marked ``needs_rebase``. How do I :ref:`rebase my PR <rebase_guide>`?
@@ -56,10 +56,12 @@ Working with the Ansible repo
 * I am ready to step up as a collection maintainer. What are the :ref:`guidelines for maintainers <maintainers>`?
 * A module in a collection I maintain is obsolete. How do I :ref:`deprecate a module <deprecating_modules>`?
 
+.. _community_toc:
+
 Traditional Table of Contents
 =============================
 
-If you prefer to read the entire Community Guide, here's a list of the pages in order:
+If you prefer to read the entire Community Guide, here is a list of the pages in order:
 
 .. toctree::
    :maxdepth: 2

docs/docsite/rst/dev_guide/developing_core.rst

@@ -1,11 +1,8 @@
-**********************************
-Developing the Ansible Core Engine
-**********************************
+***************************
+Developing ``ansible-base``
+***************************
 
-Although many of the pieces of the Ansible Core Engine are plugins that can be
-swapped out via playbook directives or configuration, there are still pieces
-of the Engine that are not modular.  The documents here give insight into how
-those pieces work together.
+Although ``ansible-base`` (the code hosted in the `ansible/ansible repository <https://github.com/ansible/ansible>`_ on GitHub) includes a few plugins that can be swapped out via playbook directives or configuration, much of the code there is not modular.  The documents here give insight into how the parts of ``ansible-base`` work together.
 
 .. toctree::
    :maxdepth: 1