Create separate core vs collection contributor guides (#76764)

* updated core guides
* ansible package docs guides
* add core guide to Ansible docs
* Update docs/docsite/rst/community/maintainers.rst

docs/docsite/rst/ansible_index.rst

@@ -40,6 +40,10 @@ Ansible releases a new major release approximately twice a year. The core applic
    :caption: Contributing to Ansible
 
    community/index
+   community/contributions_collections
+   community/contributions
+   community/advanced_index
+   dev_guide/style_guide/index
 
 .. toctree::
    :maxdepth: 2

docs/docsite/rst/community/advanced_index.rst

@@ -0,0 +1,14 @@
+.. _advanced_community_guide:
+
+**********************************************
+Advanced Contributor Guide
+**********************************************
+
+This guide focuses on contributors who are committers, GitHub admins, or release managers.
+
+.. toctree::
+   :maxdepth: 1
+
+   committer_guidelines
+   release_managers
+   github_admins

docs/docsite/rst/community/collection_development_process.rst

@@ -0,0 +1,288 @@
+.. _collection_development_process:
+
+******************************************
+The Ansible Collections Development Cycle
+******************************************
+
+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-core``. 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-core`` occurs on two levels. At the macro level, the ``ansible-core`` 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-core``.
+
+.. contents::
+   :local:
+
+
+Macro development: roadmaps, releases, and projects
+=====================================================================
+
+If you want to follow the conversation about what features will be added to the Ansible package 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>`
+* various GitHub `projects <https://github.com/ansible/ansible/projects>`_ - for example:
+
+   * the `2.12 release project <https://github.com/ansible/ansible/projects/43>`_
+
+Micro development: the lifecycle of a PR
+========================================
+
+If you want to contribute a feature or fix a bug 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-core``.
+Here's an overview of the PR lifecycle:
+
+* Contributor opens a PR
+* Ansibot reviews the PR
+* Ansibot assigns labels
+* Ansibot pings maintainers
+* Azure Pipelines runs the test suite
+* Developers, maintainers, community review the PR
+* Contributor addresses any feedback from reviewers
+* Developers, maintainers, community re-review
+* PR merged or closed
+
+Automated PR review: ansibullbot
+--------------------------------
+
+Because Ansible receives many pull requests, and because we love automating things, we have automated several steps of the process of reviewing and merging pull requests with a tool called Ansibullbot, or Ansibot for short.
+
+`Ansibullbot <https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md>`_ serves many functions:
+
+- Responds quickly to PR submitters to thank them for submitting their PR
+- Identifies the community maintainer responsible for reviewing PRs for any files affected
+- Tracks the current status of PRs
+- Pings responsible parties to remind them of any PR actions for which they may be responsible
+- Provides maintainers with the ability to move PRs through the workflow
+- Identifies PRs abandoned by their submitters so that we can close them
+- Identifies modules abandoned by their maintainers so that we can find new maintainers
+
+Ansibot workflow
+^^^^^^^^^^^^^^^^
+
+Ansibullbot runs continuously. You can generally expect to see changes to your issue or pull request within thirty minutes. Ansibullbot examines every open pull request in the repositories, and enforces state roughly according to the following workflow:
+
+-  If a pull request has no workflow labels, it's considered **new**. Files in the pull request are identified, and the maintainers of those files are pinged by the bot, along with instructions on how to review the pull request. (Note: sometimes we strip labels from a pull request to "reboot" this process.)
+-  If the module maintainer is not ``$team_ansible``, the pull request then goes into the **community_review** state.
+-  If the module maintainer is ``$team_ansible``, the pull request then goes into the **core_review** state (and probably sits for a while).
+-  If the pull request is in **community_review** and has received comments from the maintainer:
+
+   -  If the maintainer says ``shipit``, the pull request is labeled **shipit**, whereupon the Core team assesses it for final merge.
+   -  If the maintainer says ``needs_info``, the pull request is labeled **needs_info** and the submitter is asked for more info.
+   -  If the maintainer says **needs_revision**, the pull request is labeled **needs_revision** and the submitter is asked to fix some things.
+
+-  If the submitter says ``ready_for_review``, the pull request is put back into **community_review** or **core_review** and the maintainer is notified that the pull request is ready to be reviewed again.
+-  If the pull request is labeled **needs_revision** or **needs_info** and the submitter has not responded lately:
+
+   -  The submitter is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending action**, and the issue or pull request will be closed two weeks after that.
+   -  If the submitter responds at all, the clock is reset.
+-  If the pull request is labeled **community_review** and the reviewer has not responded lately:
+
+   -  The reviewer is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending_action**, and then may be reassigned to ``$team_ansible`` or labeled **core_review**, or often the submitter of the pull request is asked to step up as a maintainer.
+-  If Azure Pipelines tests fail, or if the code is not able to be merged, the pull request is automatically put into **needs_revision** along with a message to the submitter explaining why.
+
+There are corner cases and frequent refinements, but this is the workflow in general.
+
+PR labels
+^^^^^^^^^
+
+There are two types of PR Labels generally: **workflow** labels and **information** labels.
+
+Workflow labels
+"""""""""""""""
+
+-  **community_review**: Pull requests for modules that are currently awaiting review by their maintainers in the Ansible community.
+-  **core_review**: Pull requests for modules that are currently awaiting review by their maintainers on the Ansible Core team.
+-  **needs_info**: Waiting on info from the submitter.
+-  **needs_rebase**: Waiting on the submitter to rebase.
+-  **needs_revision**: Waiting on the submitter to make changes.
+-  **shipit**: Waiting for final review by the core team for potential merge.
+
+Information labels
+""""""""""""""""""
+
+-  **backport**: this is applied automatically if the PR is requested against any branch that is not devel. The bot immediately assigns the labels backport and ``core_review``.
+-  **bugfix_pull_request**: applied by the bot based on the templatized description of the PR.
+-  **cloud**: applied by the bot based on the paths of the modified files.
+-  **docs_pull_request**: applied by the bot based on the templatized description of the PR.
+-  **easyfix**: applied manually, inconsistently used but sometimes useful.
+-  **feature_pull_request**: applied by the bot based on the templatized description of the PR.
+-  **networking**: applied by the bot based on the paths of the modified files.
+-  **owner_pr**: largely deprecated. Formerly workflow, now informational. Originally, PRs submitted by the maintainer would automatically go to **shipit** based on this label. If the submitter is also a maintainer, we notify the other maintainers and still require one of the maintainers (including the submitter) to give a **shipit**.
+-  **pending_action**: applied by the bot to PRs that are not moving. Reviewed every couple of weeks by the community team, who tries to figure out the appropriate action (closure, asking for new maintainers, and so on).
+
+
+Special Labels
+""""""""""""""
+
+-  **new_plugin**: this is for new modules or plugins that are not yet in Ansible.
+
+**Note:** `new_plugin` kicks off a completely separate process, and frankly it doesn't work very well at present. We're working our best to improve this process.
+
+Human PR review
+---------------
+
+After Ansibot reviews the PR and applies labels, the PR is ready for human review. The most likely reviewers for any PR are the maintainers for the module that PR modifies.
+
+Each module has at least one assigned :ref:`maintainer <maintainers>`, listed in the `BOTMETA.yml <https://github.com/ansible/ansible/blob/devel/.github/BOTMETA.yml>`_ file.
+
+The maintainer's job is to review PRs that affect that module and decide whether they should be merged (``shipit``) or revised (``needs_revision``). We'd like to have at least one community maintainer for every module. If a module has no community maintainers assigned, the maintainer is listed as ``$team_ansible``.
+
+Once a human applies the ``shipit`` label, the :ref:`committers <community_committer_guidelines>` decide whether the PR is ready to be merged. Not every PR that gets the ``shipit`` label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches **shipit** will be mergeable.
+
+
+Making your PR merge-worthy
+===========================
+
+We do not merge every PR. Here are some tips for making your PR useful, attractive, and merge-worthy.
+
+.. _collection_changelogs:
+
+Changelogs
+----------
+
+Changelogs help users and developers keep up with changes to Ansible collections. Many collections build changelogs for each release from fragments. For ansible-core and collections using this model, you **must** add a changelog fragment to any PR that changes functionality or fixes a bug.
+
+You do not need a changelog fragment for PRs that:
+
+* add new modules and plugins, because Ansible tooling does that automatically;
+* contain only documentation changes.
+
+.. note::
+  Some collections require a changelog fragment for every pull request. They use the ``trivial:`` section for entries mentioned above that will be skipped when building a release changelog.
+
+
+More precisely:
+
+* Every bugfix PR must have a changelog fragment. The only exception are fixes to a change that has not yet been included in a release.
+* Every feature PR must have a changelog fragment.
+* New modules and plugins (except jinja2 filter and test plugins) must have ``versions_added`` set correctly, and do not need a changelog fragment. The tooling detects new modules and plugins by their ``versions_added`` value and announces them in the next release's changelog automatically.
+* New jinja2 filter and test plugins, and also new roles and playbooks (for collections) must have a changelog fragment. See :ref:`changelogs_how_to_format_j2_roles_playbooks` or the `antsibull-changelog documentation for such changelog fragments <https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelogs.rst#adding-new-roles-playbooks-test-and-filter-plugins>`_ for information on what the fragments should look like.
+
+We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR.
+
+Creating a changelog fragment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A basic changelog fragment is a ``.yaml`` or ``.yml`` file placed in the ``changelogs/fragments/`` directory.  Each file contains a yaml dict with keys like ``bugfixes`` or ``major_changes`` followed by a list of changelog entries of bugfixes or features.  Each changelog entry is rst embedded inside of the yaml file which means that certain constructs would need to be escaped so they can be interpreted by rst and not by yaml (or escaped for both yaml and rst if you prefer).  Each PR **must** use a new fragment file rather than adding to an existing one, so we can trace the change back to the PR that introduced it.
+
+PRs which add a new module or plugin do not necessarily need a changelog fragment. See the previous section :ref:`community_changelogs`. Also see the next section :ref:`changelogs_how_to_format` for the precise format changelog fragments should have.
+
+To create a changelog entry, create a new file with a unique name in the ``changelogs/fragments/`` directory of the corresponding repository. The file name should include the PR number and a description of the change. It must end with the file extension ``.yaml`` or ``.yml``. For example: ``40696-user-backup-shadow-file.yaml``
+
+A single changelog fragment may contain multiple sections but most will only contain one section. The toplevel keys (bugfixes, major_changes, and so on) are defined in the `config file <https://github.com/ansible/ansible/blob/devel/changelogs/config.yaml>`_ for our `release note tool <https://github.com/ansible-community/antsibull-changelog/blob/main/docs/changelogs.rst>`_. Here are the valid sections and a description of each:
+
+**breaking_changes**
+  Changes that break existing playbooks or roles. This includes any change to existing behavior that forces users to update tasks. Displayed in both the changelogs and the :ref:`Porting Guides <porting_guides>`.
+
+**major_changes**
+  Major changes to Ansible itself. Generally does not include module or plugin changes. Displayed in both the changelogs and the :ref:`Porting Guides <porting_guides>`.
+
+**minor_changes**
+  Minor changes to Ansible, modules, or plugins. This includes new features, new parameters added to modules, or behavior changes to existing parameters.
+
+**deprecated_features**
+  Features that have been deprecated and are scheduled for removal in a future release. Displayed in both the changelogs and the :ref:`Porting Guides <porting_guides>`.
+
+**removed_features**
+  Features that were previously deprecated and are now removed. Displayed in both the changelogs and the :ref:`Porting Guides <porting_guides>`.
+
+**security_fixes**
+  Fixes that address CVEs or resolve security concerns. Include links to CVE information.
+
+**bugfixes**
+  Fixes that resolve issues.
+
+**known_issues**
+  Known issues that are currently not fixed or will not be fixed.
+
+Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself.
+
+Most changelog entries are ``bugfixes`` or ``minor_changes``.
+
+Changelog fragment entry format
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When writing a changelog entry, use the following format:
+
+.. code-block:: yaml
+
+  - scope - description starting with a lowercase letter and ending with a period at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself).
+
+The scope is usually a module or plugin name or group of modules or plugins, for example, ``lookup plugins``. While module names can (and should) be mentioned directly (``foo_module``), plugin names should always be followed by the type (``foo inventory plugin``).
+
+For changes that are not really scoped (for example, which affect a whole collection), use the following format:
+
+.. code-block:: yaml
+
+  - Description starting with an uppercase letter and ending with a dot at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself).
+
+
+Here are some examples:
+
+.. code-block:: yaml
+
+  bugfixes:
+    - apt_repository - fix crash caused by ``cache.update()`` raising an ``IOError``
+      due to a timeout in ``apt update`` (https://github.com/ansible/ansible/issues/51995).
+
+.. code-block:: yaml
+
+  minor_changes:
+    - lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443).
+
+.. code-block:: yaml
+
+  bugfixes:
+    - copy - the module was attempting to change the mode of files for
+      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.12/changelogs/fragments>`_ for the 2.12 release.
+
+After you have written the changelog fragment for your PR, commit the file and include it with the pull request.
+
+
+Changelog fragment entry format for new jinja2 plugins, roles, and playbooks
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+While new modules and plugins that are not jinja2 filter or test plugins are mentioned automatically in the generated changelog, jinja2 filter and test plugins, roles, and playbooks are not. To make sure they are mentioned, a changelog fragment in a specific format is needed:
+
+.. code-block:: yaml
+
+    # A new jinja2 filter plugin:
+    add plugin.filter:
+      - # The following needs to be the name of the filter itself, not of the file
+        # the filter is included in!
+        name: to_time_unit
+        # The description should be in the same format as short_description for
+        # other plugins and modules: it should start with an upper-case letter and
+        # not have a period at the end.
+        description: Converts a time expression to a given unit
+
+    # A new jinja2 test plugin:
+    add plugin.test:
+      - # The following needs to be the name of the test itself, not of the file
+        # the test is included in!
+        name: asn1time
+        # The description should be in the same format as short_description for
+        # other plugins and modules: it should start with an upper-case letter and
+        # not have a period at the end.
+        description: Check whether the given string is an ASN.1 time
+
+    # A new role:
+    add object.role:
+      - # This should be the short (non-FQCN) name of the role.
+        name: nginx
+        # The description should be in the same format as short_description for
+        # plugins and modules: it should start with an upper-case letter and
+        # not have a period at the end.
+        description: A nginx installation role
+
+    # A new playbook:
+    add object.playbook:
+      - # This should be the short (non-FQCN) name of the playbook.
+        name: wipe_server
+        # The description should be in the same format as short_description for
+        # plugins and modules: it should start with an upper-case letter and
+        # not have a period at the end.
+        description: Wipes a server

docs/docsite/rst/community/communication.rst

@@ -1,8 +1,8 @@
 .. _communication:
 
-*************
-Communicating
-*************
+*****************************************
+Communicating with the Ansible community
+*****************************************
 
 .. contents::
    :local:
@@ -44,7 +44,7 @@ To join the community using Matrix, you need two things:
 * a Matrix account (from `Matrix.org <https://app.element.io/#/register>`_ or any other Matrix homeserver)
 * a `Matrix client <https://matrix.org/clients/>`_ (we recommend `Element Webchat <https://app.element.io>`_)
 
-The Ansible community maintains its own Matrix homeserver at ``ansible.im``, however public registration is currently unavailable. 
+The Ansible community maintains its own Matrix homeserver at ``ansible.im``, however public registration is currently unavailable.
 
 Matrix chat supports:
 

docs/docsite/rst/community/community.rst

@@ -1,6 +0,0 @@
-:orphan:
-
-Community Information & Contributing
-````````````````````````````````````
-
-This page is deprecated. Please see the updated :ref:`Ansible Community Guide <ansible_community_guide>`.

docs/docsite/rst/community/contributions.rst

@@ -0,0 +1,29 @@
+.. _community_contributions:
+
+********************************
+ansible-core Contributors Guide
+********************************
+
+.. toctree::
+   :maxdepth: 2
+
+   reporting_bugs_and_features
+   documentation_contributions
+   development_process
+   other_tools_and_programs
+
+
+If you have a specific Ansible interest or expertise (for example, VMware, Linode, and so on, consider joining a :ref:`working group <working_group_list>`.
+
+Working with the Ansible repo
+=============================
+
+* I want to make my first code changes to a collection or to ``ansible-core``. 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 code to meet Ansible's guidelines. Where can I find  guidance on :ref:`coding in Ansible <developer_guide>`?
+* 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>`?
+* I am using an older version of Ansible and want a bug fixed in my version that has already been fixed on the ``devel`` branch. How do I :ref:`backport a bugfix PR <backport_process>`?
+* I have an open pull request with a failing test. How do I learn about Ansible's :ref:`testing (CI) process <developing_testing>`?
+* 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>`?

docs/docsite/rst/community/contributions_collections.rst

@@ -0,0 +1,29 @@
+.. _colllections_contributions:
+
+*************************************
+Ansible Collections Contributor Guide
+*************************************
+
+.. toctree::
+   :maxdepth: 2
+
+   collection_development_process
+   reporting_collections
+   documentation_contributions
+   maintainers
+   contributing_maintained_collections
+   other_tools_and_programs
+
+
+
+If you have a specific Ansible interest or expertise (for example, VMware, Linode, and so on, consider joining a :ref:`working group <working_group_list>`.
+
+Working with the Ansible collection repositories
+=================================================
+
+* How can I find :ref:`editors, linters, and other tools <other_tools_and_programs>` that will support my Ansible development efforts?
+* Where can I find  guidance on :ref:`coding in Ansible <developer_guide>`?
+* How do I :ref:`create a collection <developing_modules_in_groups>`?
+* How do I :ref:`rebase my PR <rebase_guide>`?
+* How do I learn about Ansible's :ref:`testing (CI) process <developing_testing>`?
+* How do I :ref:`deprecate a module <deprecating_modules>`?

docs/docsite/rst/community/development_process.rst

@@ -27,6 +27,7 @@ If you want to follow the conversation about what features will be added to ``an
 
 .. _community_pull_requests:
 
+
 Micro development: the lifecycle of a PR
 ========================================
 

docs/docsite/rst/community/getting_started.rst

@@ -0,0 +1,33 @@
+.. _community_getting_started:
+
+****************
+Getting started
+****************
+
+Welcome and thank you for getting more involved with the Ansible community. Here are some ways you can get started.
+
+.. toctree::
+   :maxdepth: 2
+
+   code_of_conduct
+   contributor_license_agreement
+   communication
+   how_can_I_help
+
+
+
+Other ways to get involved
+==========================
+
+Here are some other ways to connect with the Ansible community:
+
+* Find an `Ansible Meetup near me <https://www.meetup.com/topics/ansible/>`_
+   communication
+* Learn more about Ansible:
+
+  * `Read books <https://www.ansible.com/resources/ebooks>`_.
+  * `Get certified <https://www.ansible.com/products/training-certification>`_.
+  * `Attend events <https://www.ansible.com/community/events>`_.
+  * `Review getting started guides <https://www.ansible.com/resources/get-started>`_.
+  * `Watch videos <https://www.ansible.com/resources/videos>`_ - includes Ansible Automates, AnsibleFest & webinar recordings.
+* See where `new releases are announced <https://groups.google.com/forum/#!forum/ansible-announce>`_

docs/docsite/rst/community/index.rst

@@ -14,82 +14,10 @@ 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 :ref:`traditional table of contents <community_toc>`, you can find one at the bottom of the page.
-
-
-Getting started
-===============
-
-* I am new to the community. Where can I find the Ansible :ref:`code_of_conduct`?
-* I would like to know what I am agreeing to when I contribute to Ansible. Does Ansible have a :ref:`contributor_license_agreement`?
-* I would like to contribute but I am not sure how. Are there :ref:`easy ways to contribute <how_can_i_help>`?
-* I want to talk to other Ansible users. How do I find an `Ansible Meetup near me <https://www.meetup.com/topics/ansible/>`_?
-* I have a question. Which :ref:`Ansible email lists and chat channels <communication>` will help me find answers?
-* I want to learn more about Ansible. What can I do?
-
-  * `Read books <https://www.ansible.com/resources/ebooks>`_.
-  * `Get certified <https://www.ansible.com/products/training-certification>`_.
-  * `Attend events <https://www.ansible.com/community/events>`_.
-  * `Review getting started guides <https://www.ansible.com/resources/get-started>`_.
-  * `Watch videos <https://www.ansible.com/resources/videos>`_ - includes Ansible Automates, AnsibleFest & webinar recordings.
-
-* I would like updates about new Ansible versions. How are `new releases announced <https://groups.google.com/forum/#!forum/ansible-announce>`_?
-* I want to use the current release. How do I know which :ref:`releases are current <release_schedule>`?
-
-Going deeper
-============
-
-* I think Ansible is broken. How do I :ref:`report a bug <reporting_bugs>`?
-* 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>`?
-* I would like to participate in conversations about features and fixes. How do I review GitHub issues and pull requests?
-* I found a typo or another problem on docs.ansible.com. How can I :ref:`improve the documentation <community_documentation_contributions>`?
-* Is there a :ref:`mailing list <communication>` I can sign up for to stay informed about Ansible?
-
-
-Working with the Ansible repo
-=============================
-
-* I want to make my first code changes to a collection or to ``ansible-core``. 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 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>`?
-* I am using an older version of Ansible and want a bug fixed in my version that has already been fixed on the ``devel`` branch. How do I :ref:`backport a bugfix PR <backport_process>`?
-* I have an open pull request with a failing test. How do I learn about Ansible's :ref:`testing (CI) process <developing_testing>`?
-* 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 is a list of the pages in order:
-
 .. toctree::
    :maxdepth: 2
 
-   code_of_conduct
-   how_can_I_help
-   reporting_bugs_and_features
-   documentation_contributions
-   communication
-   development_process
-   contributing_maintained_collections
-   contributor_license_agreement
-   triage_process
-   other_tools_and_programs
-   ../dev_guide/style_guide/index
-
-.. toctree::
-   :caption: Guidelines for specific types of contributors
-   :maxdepth: 1
-
-   committer_guidelines
-   maintainers
-   release_managers
-   github_admins
+   getting_started

docs/docsite/rst/community/maintainers.rst

@@ -1,8 +1,8 @@
 .. _maintainers:
 
-********************************
-Collection maintainer guidelines
-********************************
+***************************************
+Guidelines for collection maintainers
+***************************************
 
 Thank you for being a community collection maintainer. This guide offers an overview of your responsibilities as a maintainer along with resources for additional information. The Ansible community hopes that you will find that maintaining a collection is as rewarding for you as having the collection content is for the wider community.
 

docs/docsite/rst/community/reporting_bugs_and_features.rst

@@ -37,17 +37,6 @@ If you find a bug, open the issue yourself to ensure we have a record of it. Do
   * Include output where possible
   * For multiple-file content, use gist.github.com, which is more durable than pastebin content
 
-.. _reporting_bugs_in_collections:
-
-Bugs in collections
--------------------
-
-Many bugs only affect a single module or plugin. If you find a bug that affects a module or plugin hosted in a collection, file the bug in the repository of the :ref:`collection <collections>`:
-
-  #. Find the collection on `Galaxy <https://galaxy.ansible.com>`_.
-  #. Click on the Issue Tracker link for that collection.
-  #. Follow the contributor guidelines or instructions in the collection repo.
-
 If you are not sure whether a bug is in ansible-core or in a collection, you can report the behavior on the :ref:`mailing list or community chat channel first <communication>`.
 
 .. _request_features:
@@ -55,6 +44,7 @@ If you are not sure whether a bug is in ansible-core or in a collection, you can
 Requesting a feature
 ====================
 
+Before you request a feature, check what is :ref:`planned for future Ansible Releases <roadmaps>`.
 The best way to get a feature into Ansible is to :ref:`submit a pull request <community_pull_requests>`, either against ansible-core or against a collection. See also :ref:`ansible_collection_merge_requirements`.
 
 You can also submit a feature request through opening an issue in the `ansible/ansible <https://github.com/ansible/ansible/issues>`_ for ``ansible-core`` or in a corresponding collection repository (refer to the :ref:`Bugs in collections<reporting_bugs_in_collections>` section to learn how to find a proper issue tracker).

docs/docsite/rst/community/reporting_collections.rst

@@ -0,0 +1,36 @@
+.. _reporting_bugs_in_collections:
+
+***********************************
+Requesting changes to a collection
+***********************************
+
+.. contents::
+   :local:
+
+Reporting a bug
+===============
+
+Security bugs
+-------------
+
+Ansible practices responsible disclosure - if this is a security-related bug, email `security@ansible.com <mailto:security@ansible.com>`_ instead of filing a ticket or posting to any public groups, and you will receive a prompt response.
+
+
+Bugs in collections
+-------------------
+
+Many bugs only affect a single module or plugin. If you find a bug that affects a module or plugin hosted in a collection, file the bug in the repository of the :ref:`collection <collections>`:
+
+  #. Find the collection on `Galaxy <https://galaxy.ansible.com>`_.
+  #. Click on the Issue Tracker link for that collection.
+  #. Follow the contributor guidelines or instructions in the collection repo.
+
+If you are not sure whether a bug is in ansible-core or in a collection, you can report the behavior on the :ref:`mailing list or community chat channel first <communication>`.
+
+Requesting a feature
+====================
+
+Before you request a feature, check what is :ref:`planned for future Ansible Releases <roadmaps>`.
+The best way to get a feature into an Ansible collection is to :ref:`submit a pull request <community_pull_requests>`, either against ansible-core or against a collection. See also :ref:`ansible_collection_merge_requirements`.
+
+You can also submit a feature request through opening an issue in the collection repository.

docs/docsite/rst/community/triage_process.rst

@@ -1,8 +0,0 @@
-**************
-Triage Process
-**************
-
-The issue and PR triage processes are driven by the `Ansibot <https://github.com/ansible/ansibullbot>`_. Whenever an issue or PR is filed, the Ansibot examines the issue to ensure that all relevant data is present, and handles the routing of the issue as it works its way to eventual completion.
-
-For details on how Ansibot manages the triage process, please consult the `Ansibot
-Issue Guide <https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md>`_.

docs/docsite/rst/core_index.rst

@@ -51,6 +51,9 @@ This documentation covers the version of ``ansible-core`` noted in the upper lef
    :caption: Contributing to Ansible Core
 
    community/index
+   community/contributions
+   community/advanced_index
+   dev_guide/style_guide/index
 
 .. toctree::
    :maxdepth: 2

docs/docsite/rst/dev_guide/style_guide/index.rst

@@ -1,8 +1,8 @@
 .. _style_guide:
 
-*******************
-Ansible style guide
-*******************
+**********************************
+Ansible documentation style guide
+**********************************
 
 Welcome to the Ansible style guide!
 To create clear, concise, consistent, useful materials on docs.ansible.com, follow these guidelines:

docs/docsite/sphinx_conf/core_conf.py

@@ -97,6 +97,11 @@ exclude_patterns = [
     'galaxy',
     'network',
     'scenario_guides',
+    'community/contributions_collections.rst',
+    'community/reporting_collections.rst',
+    'community/contributing_maintained_collections.rst',
+    'community/collection_development_process.rst',
+    'community/maintainers.rst',
     'porting_guides/porting_guides.rst',
     'porting_guides/porting_guide_[1-9]*',
     'roadmap/index.rst',