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

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:
 
@@ -204,14 +208,14 @@ Here are some examples:
 
 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.
 
-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.
 

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
+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.
-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.
 
 .. toctree::
    :maxdepth: 1

docs/docsite/rst/dev_guide/developing_locally.rst

@@ -5,28 +5,28 @@
 Adding modules and plugins locally
 **********************************
 
-The easiest, quickest, and the most popular way to extend Ansible is to use a local module or a plugin. You can create them or copy existing ones for local use. You can store a local module or plugin on your Ansible control node and share it with your team or organization. You can also share a local plugin or module by embedding it in a role and publishing it on Ansible Galaxy. If you are using roles on Ansible Galaxy, then you are already using local modules and plugins without realizing it.
+The easiest, quickest, and the most popular way to extend Ansible is to use a local module or a plugin. You can create them or copy existing ones for local use. You can store a local module or plugin on your Ansible control node and share it with your team or organization. You can also share a local plugin or module by including it in a collection or embedding it in a role, then publishing the collection or role on Ansible Galaxy. If you are using roles on Ansible Galaxy, then you are already using local modules and plugins without realizing it.
 
-If you are using an existing module or plugin but Ansible can't find it, this page is all you need. However, if you want to create a plugin or a module, go to :ref:`developing_plugins` and :ref:`developing_modules_general` topics and then return to this page to know how to add it locally. 
+If you are using an existing module or plugin but Ansible can't find it, this page is all you need. However, if you want to create a plugin or a module, go to :ref:`developing_plugins` and :ref:`developing_modules_general` topics and then return to this page to know how to add it locally.
 
 Extending Ansible with local modules and plugins offers lots of shortcuts such as:
 
 * You can copy other people's modules and plugins.
-* If you're writing a new module, you can choose any programming language you like.
+* When writing a new module, you can choose any programming language you like.
-* You don't have to clone the main Ansible repo.
+* You do not have to clone any repositories.
-* You don't have to open a pull request.
+* You do not have to open a pull request.
-* You don't have to add tests (though we recommend that you do!).
+* You do not have to add tests (though we recommend that you do!).
 
-To save a local module or plugin such that Ansible can find and use it, add the module or plugin in the appropriate directory (the directories are specified in later parts of this topic). 
+To save a local module or plugin such that Ansible can find and use it, add the module or plugin in the appropriate directory (the directories are specified in later parts of this topic).
 
 .. contents::
    :local:
 
 .. _modules_vs_plugins:
 
-Modules and plugins: what's the difference?
+Modules and plugins: what is the difference?
-===========================================
+============================================
-If you're looking to add local functionality to Ansible, you might wonder whether you need a module or a plugin. Here's a quick overview to help you decide between the two:
+If you are looking to add local functionality to Ansible, you might wonder whether you need a module or a plugin. Here is a quick overview to help you decide between the two:
 
 * Modules are reusable, standalone scripts that can be used by the Ansible API, the :command:`ansible` command, or the :command:`ansible-playbook` command. Modules provide a defined interface. Each module accepts arguments and returns information to Ansible by printing a JSON string to stdout before exiting. Modules execute on the target system (usually that means on a remote system) in separate processes.
 * :ref:`Plugins <plugins_lookup>` augment Ansible's core functionality and execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible - transforming data, logging output, connecting to inventory, and more.
@@ -51,7 +51,7 @@ To confirm that ``my_custom_module`` is available:
 
 * type ``ansible localhost -m my_custom_module``. You should see the output for that module.
 
-or 
+or
 
 * type ``ansible-doc -t module my_custom_module``. You should see the documentation for that module.
 

docs/docsite/rst/dev_guide/developing_module_utilities.rst

@@ -1,7 +1,7 @@
 .. _developing_module_utilities:
 
 *************************************
-Using and Developing Module Utilities
+Using and developing module utilities
 *************************************
 
 Ansible provides a number of module utilities, or snippets of shared code, that
@@ -17,7 +17,7 @@ constructed dynamically for each task invocation, by extracting imports and
 resolving those matching the namespace against a :ref:`search path <ansible_search_path>` derived from the
 active configuration.
 
-To reduce the maintenance burden on your own local modules, you can extract
+To reduce the maintenance burden in a collection or in local modules, you can extract
 duplicated code into one or more module utilities and import them into your modules. For example, if you have your own custom modules that import a ``my_shared_code`` library, you can place that into a ``./module_utils/my_shared_code.py`` file like this::
 
   from ansible.module_utils.my_shared_code import MySharedCodeClient
@@ -27,14 +27,11 @@ When you run ``ansible-playbook``, Ansible will merge any files in your local ``
 Naming and finding module utilities
 ===================================
 
-You can generally tell what a module utility does from its name and/or its location. For example, ``openstack.py`` contains utilities for modules that work with OpenStack instances.
+You can generally tell what a module utility does from its name and/or its location. Generic utilities (shared code used by many different kinds of modules) live in the main ansible/ansible codebase, in the ``common`` subdirectory or in the root directory of ``lib/ansible/module_utils``. Utilities used by a particular set of modules generally live in the same collection as those modules. For example:
-Generic utilities (shared code used by many different kinds of modules) live in the ``common`` subdirectory or in the root directory. Utilities
-used by a particular set of modules generally live in a sub-directory that mirrors
-the directory for those modules. For example:
 
 * ``lib/ansible/module_utils/urls.py`` contains shared code for parsing URLs
-* ``lib/ansible/module_utils/storage/emc/`` contains shared code related to EMC
+* ``openstack.cloud.plugins.module_utils.openstack.py`` contains utilities for modules that work with OpenStack instances
-*  ``lib/ansible/modules/storage/emc/`` contains modules related to EMC
+* ``ansible.netcommon.plugins.module_utils.network.common.config.py`` contains utility functions for use by networking modules
 
 Following this pattern with your own module utilities makes everything easy to find and use.
 
@@ -43,11 +40,7 @@ Following this pattern with your own module utilities makes everything easy to f
 Standard module utilities
 =========================
 
-Ansible ships with an extensive library of ``module_utils`` files.
+Ansible ships with an extensive library of ``module_utils`` files. You can find the module utility source code in the ``lib/ansible/module_utils`` directory under your main Ansible path. We describe the most widely used utilities below. For more details on any specific module utility, please see the `source code for module_utils <https://github.com/ansible/ansible/tree/devel/lib/ansible/module_utils>`_.
-You can find the module
-utility source code in the ``lib/ansible/module_utils`` directory under
-your main Ansible path. We've described the most widely used utilities below. For more details on any specific module utility,
-please see the `source code for module_utils <https://github.com/ansible/ansible/tree/devel/lib/ansible/module_utils>`_.
 
 .. include:: shared_snippets/licensing.txt
 
@@ -55,23 +48,22 @@ please see the `source code for module_utils <https://github.com/ansible/ansible
 - ``basic.py`` - General definitions and helper utilities for Ansible modules
 - ``common/dict_transformations.py`` - Helper functions for dictionary transformations
 - ``common/file.py`` - Helper functions for working with files
-- ``common/text/`` - Helper functions for converting and formatting text.
+- ``common/text/`` - Helper functions for converting and formatting text
 - ``common/parameters.py`` - Helper functions for dealing with module parameters
 - ``common/sys_info.py`` - Functions for getting distribution and platform information
 - ``common/validation.py`` - Helper functions for validating module parameters against a module argument spec
 - ``facts/`` - Directory of utilities for modules that return facts. See `PR 23012 <https://github.com/ansible/ansible/pull/23012>`_ for more information
-- ``ismount.py`` - Single helper function that fixes os.path.ismount
 - ``json_utils.py`` - Utilities for filtering unrelated output around module JSON output, like leading and trailing lines
-- ``known_hosts.py`` - utilities for working with known_hosts file
-- ``network/common/config.py`` - Configuration utility functions for use by networking modules
-- ``network/common/netconf.py`` - Definitions and helper functions for modules that use Netconf transport
-- ``network/common/parsing.py`` - Definitions and helper functions for Network modules
-- ``network/common/network.py`` - Functions for running commands on networking devices
-- ``network/common/utils.py`` - Defines commands and comparison operators and other utilises for use in networking modules
 - ``powershell/`` - Directory of definitions and helper functions for Windows PowerShell modules
 - ``pycompat24.py`` - Exception workaround for Python 2.4
 - ``service.py`` - Utilities to enable modules to work with Linux services (placeholder, not in use)
-- ``shell.py`` - Functions to allow modules to create shells and work with shell commands
 - ``six/__init__.py`` - Bundled copy of the `Six Python library <https://pypi.org/project/six/>`_ to aid in writing code compatible with both Python 2 and Python 3
 - ``splitter.py`` - String splitting and manipulation utilities for working with Jinja2 templates
 - ``urls.py`` - Utilities for working with http and https requests
+
+Several commonly-used utilities migrated to collections in Ansible 2.10, including:
+
+- ``ismount.py`` migrated to ``ansible.posix.plugins.module_utils.mount.py`` - Single helper function that fixes os.path.ismount
+- ``known_hosts.py`` migrated to ``community.general.plugins.module_utils.known_hosts.py`` - utilities for working with known_hosts file
+
+For a list of migrated content with destination collections, see https://github.com/ansible/ansible/blob/devel/lib/ansible/config/ansible_builtin_runtime.yml.

docs/docsite/rst/dev_guide/developing_modules.rst

@@ -5,41 +5,31 @@
 Should you develop a module?
 ****************************
 
-Developing Ansible modules is easy, but often it isn't necessary. Before you start writing a new module, ask:
+Developing Ansible modules is easy, but often it is not necessary. Before you start writing a new module, ask:
 
 1. Does a similar module already exist?
 
-An existing module may cover the functionality you want. Ansible Core includes thousands of modules. Search our :ref:`list of existing modules <all_modules>` to see if there's a module that does what you need.
+An existing module may cover the functionality you want. Ansible collections include thousands of modules. Search our :ref:`list of included collections <list_of_collections>` or `Ansible Galaxy <https://galaxy.ansible.com>`_ to see if an existing module does what you need.
 
-2. Does a Pull Request already exist?
+2. Should you use or develop an action plugin instead of a module?
-
-An existing Pull Request may cover the functionality you want. If someone else has already started developing a similar module, you can review and test it. There are a few ways to find open module Pull Requests:
-
-* `GitHub new module PRs <https://github.com/ansible/ansible/labels/new_module>`_
-* `All updates to modules <https://github.com/ansible/ansible/labels/module>`_
-* `New module PRs listed by directory <https://ansible.sivel.net/pr/byfile.html>`_ search for `lib/ansible/modules/`
-
-If you find an existing PR that looks like it addresses your needs, please provide feedback on the PR. Community feedback speeds up the review and merge process.
-
-3. Should you use or develop an action plugin instead?
 
 An action plugin may be the best way to get the functionality you want. Action plugins run on the control node instead of on the managed node, and their functionality is available to all modules. For more information about developing plugins, read the :ref:`developing plugins page <developing_plugins>`.
 
-4. Should you use a role instead?
+3. Should you use a role instead of a module?
 
 A combination of existing modules may cover the functionality you want. You can write a role for this type of use case. Check out the :ref:`roles documentation<playbooks_reuse_roles>`.
 
-5. Should you write multiple modules instead of one module?
+4. Should you create a collection instead of a single module?
 
-The functionality you want may be too large for a single module. If you want to connect Ansible to a new cloud provider, database, or network platform, you may need to :ref:`develop a related group of modules<developing_modules_in_groups>`.
+The functionality you want may be too large for a single module. If you want to connect Ansible to a new cloud provider, database, or network platform, you may need to :ref:`develop a new collection<developing_modules_in_groups>`.
 
-* Modules should have a concise and well defined functionality. Basically, follow the UNIX philosophy of doing one thing well.
+* Each module should have a concise and well defined functionality. Basically, follow the UNIX philosophy of doing one thing well.
 
-* Modules should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module parameter cannot be documented, that's a sign that the module would be rejected.
+* A module should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module parameter cannot be documented, that's a sign that the module would be rejected.
 
 * Modules should typically encompass much of the logic for interacting with a resource. A lightweight wrapper around an API that does not contain much logic would likely cause users to offload too much logic into a playbook, and for this reason the module would be rejected. Instead try creating multiple modules for interacting with smaller individual pieces of the API.
 
-If your use case isn't covered by an existing module, an open PR, an action plugin, or a role, and you don't need to create multiple modules, then you're ready to start developing a new module. Choose from the topics below for next steps:
+If your use case isn't covered by an existing module, an action plugin, or a role, and you don't need to create multiple modules, then you're ready to start developing a new module. Choose from the topics below for next steps:
 
 * I want to :ref:`get started on a new module <developing_modules_general>`.
 * I want to review :ref:`tips and conventions for developing good modules <developing_modules_best_practices>`.
@@ -53,10 +43,8 @@ If your use case isn't covered by an existing module, an open PR, an action plug
 
 .. seealso::
 
-   :ref:`all_modules`
+   :ref:`list_of_collections`
-       Learn about available modules
+       Browse existing collections, modules, and plugins
-   `GitHub modules directory <https://github.com/ansible/ansible/tree/devel/lib/ansible/modules>`_
-       Browse module source code
    `Mailing List <https://groups.google.com/group/ansible-devel>`_
        Development mailing list
    `irc.freenode.net <http://irc.freenode.net>`_

docs/docsite/rst/dev_guide/developing_modules_best_practices.rst

@@ -13,7 +13,7 @@ As you design and develop modules, follow these basic conventions and tips for c
 Scoping your module(s)
 ======================
 
-Especially if you want to contribute your module(s) back to Ansible Core, make sure each module includes enough logic and functionality, but not too much. If you're finding these guidelines tricky, consider :ref:`whether you really need to write a module <module_dev_should_you>` at all.
+Especially if you want to contribute your module(s) to an existing Ansible Collection, make sure each module includes enough logic and functionality, but not too much. If these guidelines seem confusing, consider :ref:`whether you really need to write a module <module_dev_should_you>` at all.
 
 * Each module should have a concise and well-defined functionality. Basically, follow the UNIX philosophy of doing one thing well.
 * Do not add ``get``, ``list`` or ``info`` state options to an existing module - create a new ``_info`` or ``_facts`` module.
@@ -31,8 +31,8 @@ Designing module interfaces
 General guidelines & tips
 =========================
 
-* Each module should be self-contained in one file, so it can be auto-transferred by Ansible.
+* Each module should be self-contained in one file, so it can be auto-transferred by ``ansible-base``.
-* Module name MUST use underscores instead of hyphens or spaces as a word separator. Using hyphens and spaces will prevent Ansible from importing your module.
+* Module name MUST use underscores instead of hyphens or spaces as a word separator. Using hyphens and spaces will prevent ``ansible-base`` from importing your module.
 * Always use the ``hacking/test-module.py`` script when developing modules - it will warn you about common pitfalls.
 * If you have a local module that returns facts specific to your installations, a good name for this module is ``site_facts``.
 * Eliminate or minimize dependencies. If your module has dependencies, document them at the top of the module file and raise JSON error messages when dependency import fails.
@@ -46,7 +46,7 @@ Functions and Methods
 * Each function should be concise and should describe a meaningful amount of work.
 * "Don't repeat yourself" is generally a good philosophy.
 * Function names should use underscores: ``my_function_name``.
-* Each function's name should describes what it does.
+* The name of each function should describe what the function does.
 * Each function should have a docstring.
 * If your code is too nested, that's usually a sign the loop body could benefit from being a function. Parts of our existing code are not the best examples of this at times.
 

docs/docsite/rst/dev_guide/developing_modules_checklist.rst

@@ -1,18 +1,18 @@
 .. _developing_modules_checklist:
 .. _module_contribution:
 
-***********************************
+**********************************************************
-Contributing your module to Ansible
+Contributing your module to an existing Ansible collection
-***********************************
+**********************************************************
 
-If you want to contribute a module to Ansible, you must meet our objective and subjective requirements. Please read the details below, and also review our :ref:`tips for module development <developing_modules_best_practices>`.
+If you want to contribute a module to an existing collection, you must meet the community's objective and subjective requirements. Please read the details below, and also review our :ref:`tips for module development <developing_modules_best_practices>`.
 
-Modules accepted into the `main project repo <https://github.com/ansible/ansible>`_ ship with every Ansible installation. However, contributing to the main project isn't the only way to distribute a module - you can embed modules in roles on Galaxy or simply share copies of your module code for :ref:`local use <developing_locally>`.
+Modules accepted into certain collections are included in every Ansible release on PyPI. However, contributing to one of these collections is not the only way to distribute a module - you can :ref:`create your own collection <developing_collections>`, embed modules in roles on Galaxy or simply share copies of your module code for :ref:`local use <developing_locally>`.
 
-Contributing to Ansible: objective requirements
+Contributing modules: objective requirements
 ===============================================
 
-To contribute a module to Ansible, you must:
+To contribute a module to most Ansible collections, you must:
 
 * write your module in either Python or Powershell for Windows
 * use the ``AnsibleModule`` common code
@@ -29,12 +29,14 @@ To contribute a module to Ansible, you must:
 * if a module is named ``<something>_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed.
 * Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine.
 
+Additional requirements may apply for certain collections. Review the individual collection repositories for more information.
+
 Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out via `Ansible's IRC chat channel <http://irc.freenode.net>`_ or the `Ansible development mailing list <https://groups.google.com/group/ansible-devel>`_.
 
 Contributing to Ansible: subjective requirements
 ================================================
 
-If your module meets our objective requirements, we'll review your code to see if we think it's clear, concise, secure, and maintainable. We'll consider whether your module provides a good user experience, helpful error messages, reasonable defaults, and more. This process is subjective, and we can't list exact standards for acceptance. For the best chance of getting your module accepted into the Ansible repo, follow our :ref:`tips for module development <developing_modules_best_practices>`.
+If your module meets these objective requirements, collection maintainers will review your code to see if they think it's clear, concise, secure, and maintainable. They will consider whether your module provides a good user experience, helpful error messages, reasonable defaults, and more. This process is subjective, with no exact standards for acceptance. For the best chance of getting your module accepted, follow our :ref:`tips for module development <developing_modules_best_practices>`.
 
 Other checklists
 ================

docs/docsite/rst/dev_guide/developing_modules_documenting.rst

@@ -5,7 +5,7 @@
 Module format and documentation
 *******************************
 
-If you want to contribute your module to Ansible, you must write your module in Python and follow the standard format described below. (Unless you're writing a Windows module, in which case the :ref:`Windows guidelines <developing_modules_general_windows>` apply.) In addition to following this format, you should review our :ref:`submission checklist <developing_modules_checklist>`, :ref:`programming tips <developing_modules_best_practices>`, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility <developing_python_3>`, as well as information about :ref:`testing <developing_testing>` before you open a pull request.
+If you want to contribute your module to most Ansible collections, you must write your module in Python and follow the standard format described below. (Unless you're writing a Windows module, in which case the :ref:`Windows guidelines <developing_modules_general_windows>` apply.) In addition to following this format, you should review our :ref:`submission checklist <developing_modules_checklist>`, :ref:`programming tips <developing_modules_best_practices>`, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility <developing_python_3>`, as well as information about :ref:`testing <developing_testing>` before you open a pull request.
 
 Every Ansible module written in Python must begin with seven standard sections in a particular order, followed by the code. The sections in order are:
 
@@ -19,22 +19,21 @@ Every Ansible module written in Python must begin with seven standard sections i
 
 .. warning:: **Copy old modules with care!**
 
-  Some older modules in Ansible Core have ``imports`` at the bottom of the file, ``Copyright`` notices with the full GPL prefix, and/or ``DOCUMENTATION`` fields in the wrong order. These are legacy files that need updating - do not copy them into new modules. Over time we're updating and correcting older modules. Please follow the guidelines on this page!
+  Some older Ansible modules have ``imports`` at the bottom of the file, ``Copyright`` notices with the full GPL prefix, and/or ``DOCUMENTATION`` fields in the wrong order. These are legacy files that need updating - do not copy them into new modules. Over time we are updating and correcting older modules. Please follow the guidelines on this page!
 
 .. _shebang:
 
 Python shebang & UTF-8 coding
 ===============================
 
-Every Ansible module must begin with ``#!/usr/bin/python`` - this "shebang" allows ``ansible_python_interpreter`` to work.
+Begin your Ansible module with ``#!/usr/bin/python`` - this "shebang" allows ``ansible_python_interpreter`` to work. Follow the shebang immediately with ``# -*- coding: utf-8 -*-`` to clarify that the file is UTF-8 encoded.
-This is immediately followed by ``# -*- coding: utf-8 -*-`` to clarify that the file is UTF-8 encoded.
 
 .. _copyright:
 
 Copyright and license
 =====================
 
-After the shebang and UTF-8 coding, there should be a `copyright line <https://www.gnu.org/licenses/gpl-howto.en.html>`_ with the original copyright holder and a license declaration. The license declaration should be ONLY one line, not the full GPL prefix.:
+After the shebang and UTF-8 coding, add a `copyright line <https://www.gnu.org/licenses/gpl-howto.en.html>`_ with the original copyright holder and a license declaration. The license declaration should be ONLY one line, not the full GPL prefix.:
 
 .. code-block:: python
 
@@ -185,7 +184,7 @@ All fields in the ``DOCUMENTATION`` block are lower-case. All fields are require
   :suboptions:
 
     * If this option takes a dict or list of dicts, you can define the structure here.
-    * See :ref:`azure_rm_securitygroup_module`, :ref:`azure_rm_azurefirewall_module` and :ref:`os_ironic_node_module` for examples.
+    * See :ref:`ansible_collections.azure.azcollection.azure_rm_securitygroup_module`, :ref:`ansible_collections.azure.azcollection.azure_rm_azurefirewall_module`, and :ref:`ansible_collections.openstack.cloud.baremetal_node_action_module` for examples.
 
 :requirements:
 
@@ -265,7 +264,7 @@ content in a uniform way:
 Documentation fragments
 -----------------------
 
-If you're writing multiple related modules, they may share common documentation, such as authentication details, file mode settings, ``notes:`` or ``seealso:`` entries. Rather than duplicate that information in each module's ``DOCUMENTATION`` block, you can save it once as a doc_fragment plugin and use it in each module's documentation. In Ansible, shared documentation fragments are contained in a ``ModuleDocFragment`` class in `lib/ansible/plugins/doc_fragments/ <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/doc_fragments>`_. To include a documentation fragment, add ``extends_documentation_fragment: FRAGMENT_NAME`` in your module's documentation.
+If you are writing multiple related modules, they may share common documentation, such as authentication details, file mode settings, ``notes:`` or ``seealso:`` entries. Rather than duplicate that information in each module's ``DOCUMENTATION`` block, you can save it once as a doc_fragment plugin and use it in each module's documentation. In Ansible, shared documentation fragments are contained in a ``ModuleDocFragment`` class in `lib/ansible/plugins/doc_fragments/ <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/doc_fragments>`_ or the equivalent directory in a collection. To include a documentation fragment, add ``extends_documentation_fragment: FRAGMENT_NAME`` in your module documentation. Use the fully qualified collection name for the FRAGMENT_NAME (for example, ``community.kubernetes.k8s_auth_options``).
 
 Modules should only use items from a doc fragment if the module will implement all of the interface documented there in a manner that behaves the same as the existing modules which import that fragment. The goal is that items imported from the doc fragment will behave identically when used in another module that imports the doc fragment.
 

docs/docsite/rst/dev_guide/developing_modules_general.rst

@@ -9,7 +9,7 @@ A module is a reusable, standalone script that Ansible runs on your behalf, eith
 
 If you need functionality that is not available in any of the thousands of Ansible modules found in collections, you can easily write your own custom module. When you write a module for local use, you can choose any programming language and follow your own rules. Use this topic to learn how to create an Ansible module in Python. After you create a module, you must add it locally to the appropriate directory so that Ansible can find and execute it. For details about adding a module locally, see :ref:`developing_locally`.
 
-.. contents:: Topics
+.. contents::
    :local:
 
 .. _environment_setup:
@@ -91,7 +91,7 @@ Creating a module
 
 To create a module:
 
-1. Navigate to the correct directory for your new module: ``$ cd lib/ansible/modules/``. If you are developing module using collection, ``$ cd plugins/modules/`` inside your collection development tree.
+1. Navigate to the correct directory for your new module: ``$ cd lib/ansible/modules/``. If you are developing a module in a :ref:`collection <developing_collections>`, ``$ cd plugins/modules/`` inside your collection development tree.
 2. Create your new module file: ``$ touch my_test.py``.
 3. Paste the content below into your new module file. It includes the :ref:`required Ansible format and documentation <developing_modules_documenting>` and some example code.
 4. Modify and extend the code to do what you want your new module to do. See the :ref:`programming tips <developing_modules_best_practices>` and :ref:`Python 3 compatibility <developing_python_3>` pages for pointers on writing clean and concise module code.
@@ -102,7 +102,7 @@ To create a module:
 Verifying your module code
 ==========================
 
-Once you've modified the sample code above to do what you want, you can try out your module.
+After you modify the sample code above to do what you want, you can try out your module.
 Our :ref:`debugging tips <debugging_modules>` will help if you run into bugs as you verify your module code.
 
 
@@ -196,19 +196,10 @@ test/units/modules/.../test/my_test.py``
 Contributing back to Ansible
 ============================
 
-If you would like to contribute to the main Ansible repository
+If you would like to contribute to ``ansible-base`` by adding a new feature or fixing a bug, `create a fork <https://help.github.com/articles/fork-a-repo/>`_ of the ansible/ansible repository and develop against a new feature branch using the ``devel`` branch as a starting point. When you you have a good working code change, you can submit a pull request to the Ansible repository by selecting your feature branch as a source and the Ansible devel branch as a target.
-by adding a new feature or fixing a bug, `create a fork <https://help.github.com/articles/fork-a-repo/>`_
+
-of the Ansible repository and develop against a new feature
+If you want to contribute a module to an :ref:`Ansible collection <contributing_maintained_collections>`, review our :ref:`submission checklist <developing_modules_checklist>`, :ref:`programming tips <developing_modules_best_practices>`, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility <developing_python_3>`, as well as information about :ref:`testing <developing_testing>` before you open a pull request.
-branch using the ``devel`` branch as a starting point.
-When you you have a good working code change, you can
-submit a pull request to the Ansible repository by selecting
-your feature branch as a source and the Ansible devel branch as
-a target.
 
-If you want to contribute your module back to the upstream Ansible repo,
-review our :ref:`submission checklist <developing_modules_checklist>`, :ref:`programming tips <developing_modules_best_practices>`,
-and :ref:`strategy for maintaining Python 2 and Python 3 compatibility <developing_python_3>`, as well as
-information about :ref:`testing <developing_testing>` before you open a pull request.
 The :ref:`Community Guide <ansible_community_guide>` covers how to open a pull request and what happens next.
 
 

docs/docsite/rst/dev_guide/developing_modules_general_aci.rst

@@ -18,9 +18,9 @@ What's covered in this section:
 
 Introduction
 ============
-Ansible already ships with a large collection of Cisco ACI modules, however the ACI object model is huge and covering all possible functionality would easily cover more than 1500 individual modules.
+The `cisco.aci collection <https://galaxy.ansible.com/cisco/aci>`_ already includes a large number of Cisco ACI modules, however the ACI object model is huge and covering all possible functionality would easily cover more than 1500 individual modules.
 
-If you are in need of specific functionality, you have 2 options:
+If you need specific functionality, you have 2 options:
 
 - Learn the ACI object model and use the low-level APIC REST API using the :ref:`aci_rest <aci_rest_module>` module
 - Write your own dedicated modules, which is actually quite easy

docs/docsite/rst/dev_guide/developing_plugins.rst

@@ -8,7 +8,7 @@ Developing plugins
 .. contents::
    :local:
 
-Plugins augment Ansible's core functionality with logic and features that are accessible to all modules. Ansible ships with a number of handy plugins, and you can easily write your own. All plugins must:
+Plugins augment Ansible's core functionality with logic and features that are accessible to all modules. Ansible collections include a number of handy plugins, and you can easily write your own. All plugins must:
 
 * be written in Python
 * raise errors
@@ -70,8 +70,7 @@ To define configurable options for your plugin, describe them in the ``DOCUMENTA
 
 To access the configuration settings in your plugin, use ``self.get_option(<option_name>)``. For most plugin types, the controller pre-populates the settings. If you need to populate settings explicitly, use a ``self.set_options()`` call.
 
-
+Plugins that support embedded documentation (see :ref:`ansible-doc` for the list) should include well-formed doc strings. If you inherit from a plugin, you must document the options it takes, either via a documentation fragment or as a copy. See :ref:`module_documenting` for more information on correct documentation. Thorough documentation is a good idea even if you're developing a plugin for local use.
-Plugins that support embedded documentation (see :ref:`ansible-doc` for the list) must include well-formed doc strings to be considered for merge into the Ansible repo. If you inherit from a plugin, you must document the options it takes, either via a documentation fragment or as a copy. See :ref:`module_documenting` for more information on correct documentation. Thorough documentation is a good idea even if you're developing a plugin for local use.
 
 Developing particular plugin types
 ==================================

docs/docsite/rst/dev_guide/developing_program_flow_modules.rst

@@ -5,7 +5,7 @@
 Ansible module architecture
 ***************************
 
-If you're working on Ansible's Core code, writing an Ansible module, or developing an action plugin, this deep dive helps you understand how Ansible's program flow executes. If you're just using Ansible Modules in playbooks, you can skip this section.
+If you are working on the ``ansible-base`` code, writing an Ansible module, or developing an action plugin, you may need to understand how Ansible's program flow executes. If you are just using Ansible Modules in playbooks, you can skip this section.
 
 .. contents::
    :local:

docs/docsite/rst/dev_guide/developing_python_3.rst

@@ -4,14 +4,11 @@
 Ansible and Python 3
 ********************
 
-.. contents:: Topics
+The ``ansible-base`` code runs on both Python 2 and Python 3 because we want Ansible to be able to manage a wide
-   :local:
+variety of machines. Contributors to ansible-base 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.
 
-Ansible maintains a single code base that runs on both
+.. contents::
-Python 2 and Python 3 because we want Ansible to be able to manage a wide
+   :local:
-variety of machines.  Contributors to Ansible 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.
 
 To ensure that your code runs on Python 3 as well as on Python 2, learn the tips and tricks and idioms
 described here. Most of these considerations apply to all three types of Ansible code:
@@ -20,8 +17,7 @@ described here. Most of these considerations apply to all three types of Ansible
 2. modules - the code which Ansible transmits to and invokes on the managed machine.
 3. shared ``module_utils`` code - the common code that's used by modules to perform tasks and sometimes used by controller-side code as well
 
-However, the three types of code do not use the same string strategy. If you're developing a module or some ``module_utils`` code, be sure
+However, the three types of code do not use the same string strategy. If you're developing a module or some ``module_utils`` code, be sure to read the section on string strategy carefully.
-to read the section on string strategy carefully.
 
 Minimum version of Python 3.x and Python 2.x
 ============================================
@@ -405,8 +401,4 @@ does have support for the older, percent-formatting.
 Testing modules on Python 3
 ===================================
 
-Ansible modules are slightly harder to code to support Python 3 than normal code from other
+Ansible modules are slightly harder to code to support Python 3 than normal code from other projects. A lot of mocking has to go into unit testing an Ansible module, so it's harder to test that your changes have fixed everything or to to make sure that later commits haven't regressed the Python 3 support. Review our :ref:`testing <developing_testing>` pages for more information.
-projects. A lot of mocking has to go into unit testing an Ansible module, so
-it's harder to test that your changes have fixed everything or to to make sure
-that later commits haven't regressed the Python 3 support. Review our :ref:`testing <developing_testing>` pages
-for more information.

docs/docsite/rst/dev_guide/developing_rebasing.rst

@@ -14,8 +14,7 @@ Rebasing the branch used to create your PR will resolve both of these issues.
 Configuring your remotes
 ========================
 
-Before you can rebase your PR, you need to make sure you have the proper remotes configured.
+Before you can rebase your PR, you need to make sure you have the proper remotes configured. These instructions apply to any repository on GitHub, including collections repositories. On other platforms (bitbucket, gitlab), the same principles and commands apply but the syntax may be different. We use the ansible/ansible repository here as an example. In other repositories, the branch names may be different. Assuming you cloned your fork in the usual fashion, the ``origin`` remote will point to your fork::
-Assuming you cloned your fork in the usual fashion, the ``origin`` remote will point to your fork::
 
    $ git remote -v
    origin  git@github.com:YOUR_GITHUB_USERNAME/ansible.git (fetch)
@@ -33,7 +32,7 @@ Which should leave you with the following remotes::
    upstream        https://github.com/ansible/ansible.git (fetch)
    upstream        https://github.com/ansible/ansible.git (push)
 
-Checking the status of your branch should show you're up-to-date with your fork at the ``origin`` remote::
+Checking the status of your branch should show your fork is up-to-date with the ``origin`` remote::
 
    $ git status
    On branch YOUR_BRANCH
@@ -50,7 +49,7 @@ Once you have an ``upstream`` remote configured, you can rebase the branch for y
 This will replay the changes in your branch on top of the changes made in the upstream ``devel`` branch.
 If there are merge conflicts, you will be prompted to resolve those before you can continue.
 
-Once you've rebased, the status of your branch will have changed::
+After you rebase, the status of your branch changes::
 
    $ git status
    On branch YOUR_BRANCH
@@ -59,8 +58,7 @@ Once you've rebased, the status of your branch will have changed::
      (use "git pull" to merge the remote branch into yours)
    nothing to commit, working tree clean
 
-Don't worry, this is normal after a rebase. You should ignore the ``git status`` instructions to use ``git pull``.
+Don't worry, this is normal after a rebase. You should ignore the ``git status`` instructions to use ``git pull``. We'll cover what to do next in the following section.
-We'll cover what to do next in the following section.
 
 Updating your pull request
 ==========================
@@ -77,8 +75,7 @@ You should check in on the status of your PR after tests have completed to see i
 Getting help rebasing
 =====================
 
-For help with rebasing your PR, or other development related questions, join us on our #ansible-devel IRC chat channel
+For help with rebasing your PR, or other development related questions, join us on our #ansible-devel IRC chat channel on `freenode.net <https://freenode.net>`_.
-on `freenode.net <https://freenode.net>`_.
 
 .. seealso::
 

docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst

@@ -4,12 +4,7 @@
 Guidelines for Ansible Amazon AWS module development
 ****************************************************
 
-The Ansible AWS modules and these guidelines are maintained by the Ansible AWS Working Group.  For
+The Ansible AWS collection (on `Galaxy <https://galaxy.ansible.com/community/aws>`_, source code `repository <https://github.com/ansible-collections/community.aws>`_) is maintained by the Ansible AWS Working Group.  For further information see the `AWS working group community page <https://github.com/ansible/community/wiki/aws>`_. If you are planning to contribute AWS modules to Ansible then getting in touch with the working group is a good way to start, especially because a similar module may already be under development.
-further information see
-the `AWS working group community page <https://github.com/ansible/community/wiki/aws>`_.
-If you are planning to contribute AWS modules to Ansible then getting in touch with the working
-group will be a good way to start, especially because a similar module may already be under
-development.
 
 .. contents::
    :local:
@@ -156,7 +151,7 @@ or:
 Supporting Module Defaults
 --------------------------
 
-The existing AWS modules support using :ref:`module_defaults <module_defaults>` for common 
+The existing AWS modules support using :ref:`module_defaults <module_defaults>` for common
 authentication parameters.  To do the same for your new module, add an entry for it in
 ``lib/ansible/config/module_defaults.yml``.  These entries take the form of:
 

docs/docsite/rst/dev_guide/platforms/openstack_guidelines.rst

@@ -3,10 +3,7 @@
 OpenStack Ansible Modules
 =========================
 
-These are a set of modules for interacting with OpenStack as either an admin
+The OpenStack collection (on `Galaxy <https://galaxy.ansible.com/openstack/cloud>`_, source code `repository <https://opendev.org/openstack/ansible-collections-openstack.git>`_) contains modules for interacting with OpenStack as either an admin or an end user. If the module does not begin with ``os_``, it is either deprecated or soon to be deprecated. This document serves as developer coding guidelines for modules in this collection.
-or an end user. If the module does not begin with ``os_``, it's either deprecated
-or soon to be. This document serves as developer coding guidelines for
-modules intended to be here.
 
 .. contents::
    :local:

docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst

@@ -3,8 +3,7 @@
 oVirt Ansible Modules
 =====================
 
-This is a set of modules for interacting with oVirt/RHV. This document
+The set of modules for interacting with oVirt/RHV are currently part of the community.general collection (on `Galaxy <https://galaxy.ansible.com/community/general>`_, source code `repository <https://github.com/ansible-collections/community.general/tree/main/plugins/modules/cloud/ovirt>`_). This document serves as developer coding guidelines for creating oVirt/RHV modules.
-serves as developer coding guidelines for creating oVirt/RHV modules.
 
 .. contents::
    :local:

docs/docsite/rst/dev_guide/platforms/vmware_guidelines.rst

@@ -4,8 +4,7 @@
 Guidelines for VMware module development
 ****************************************
 
-The VMware modules and these guidelines are maintained by the VMware Working Group. For
+The Ansible VMware collection (on `Galaxy <https://galaxy.ansible.com/community/vmware>`_, source code `repository <https://github.com/ansible-collections/vmware>`_) is maintained by the VMware Working Group. For further information see the `team community page <https://github.com/ansible/community/wiki/VMware>`_.
-further information see the `team community page <https://github.com/ansible/community/wiki/VMware>`_.
 
 .. contents::
    :local: