Bulk rst/community backport (#28896)

9 files changed, 554 insertions, 0 deletions

diff --git a/docs/docsite/rst/community/code_of_conduct.rst b/docs/docsite/rst/community/code_of_conduct.rst
new file mode 100644
index 0000000000..000d43e12b
--- /dev/null
+++ b/docs/docsite/rst/community/code_of_conduct.rst
@@ -0,0 +1,144 @@
+*************************
+Community Code of Conduct
+*************************
+
+.. contents:: Topics
+
+Every community can be strengthened by a diverse variety of viewpoints, insights,
+opinions, skillsets, and skill levels. However, with diversity comes the potential for
+disagreement and miscommunication. The purpose of this Code of Conduct is to ensure that
+disagreements and differences of opinion are conducted respectfully and on their own
+merits, without personal attacks or other behavior that might create an unsafe or
+unwelcoming environment.
+
+These policies are not designed to be a comprehensive set of Things You Cannot Do. We ask
+that you treat your fellow community members with respect and courtesy, and in general,
+Don't Be A Jerk. This Code of Conduct is meant to be followed in spirit as much as in
+letter and is not exhaustive.
+
+All Ansible events and participants therein are governed by this Code of Conduct and
+anti-harassment policy. We expect organizers to enforce these guidelines throughout all events,
+and we expect attendees, speakers, sponsors, and volunteers to help ensure a safe
+environment for our whole community. Specifically, this Code of Conduct covers
+participation in all Ansible-related forums and mailing lists, code and documentation
+contributions, public IRC channels, private correspondence, and public meetings.
+
+Ansible community members are...
+
+**Considerate**
+
+Contributions of every kind have far-ranging consequences. Just as your work depends on
+the work of others, decisions you make surrounding your contributions to the Ansible
+community will affect your fellow community members. You are strongly encouraged to take
+those consequences into account while making decisions.
+
+**Patient**
+
+Asynchronous communication can come with its own frustrations, even in the most responsive
+of communities. Please remember that our community is largely built on volunteered time,
+and that questions, contributions, and requests for support may take some time to receive
+a response. Repeated "bumps" or "reminders" in rapid succession are not good displays of
+patience. Additionally, it is considered poor manners to ping a specific person with
+general questions. Pose your question to the community as a whole, and wait patiently for
+a response.
+
+**Respectful**
+
+Every community inevitably has disagreements, but remember that it is
+possible to disagree respectfully and courteously. Disagreements are never an excuse for
+rudeness, hostility, threatening behavior, abuse (verbal or physical), or personal attacks.
+
+**Kind**
+
+Everyone should feel welcome in the Ansible community, regardless of their background.
+Please be courteous, respectful and polite to fellow community members. Do not make or
+post offensive comments related to skill level, gender, gender identity or expression,
+sexual orientation, disability, physical appearance, body size, race, or religion.
+Sexualized images or imagery, real or implied violence, intimidation, oppression,
+stalking, sustained disruption of activities, publishing the personal information of
+others without explicit permission to do so, unwanted physical contact, and unwelcome
+sexual attention are all strictly prohibited.  Additionally, you are encouraged not to
+make assumptions about the background or identity of your fellow community members.
+
+**Inquisitive**
+
+The only stupid question is the one that does not get asked. We
+encourage our users to ask early and ask often. Rather than asking whether you can ask a
+question (the answer is always yes!), instead, simply ask your question. You are
+encouraged to provide as many specifics as possible. Code snippets in the form of Gists or
+other paste site links are almost always needed in order to get the most helpful answers.
+Refrain from pasting multiple lines of code directly into the IRC channels - instead use
+gist.github.com or another paste site to provide code snippets.
+
+**Helpful**
+
+The Ansible community is committed to being a welcoming environment for all users,
+regardless of skill level. We were all beginners once upon a time, and our community
+cannot grow without an environment where new users feel safe and comfortable asking questions.
+It can become frustrating to answer the same questions repeatedly; however, community
+members are expected to remain courteous and helpful to all users equally, regardless of
+skill or knowledge level. Avoid providing responses that prioritize snideness and snark over
+useful information. At the same time, everyone is expected to read the provided
+documentation thoroughly. We are happy to answer questions, provide strategic guidance,
+and suggest effective workflows, but we are not here to do your job for you.
+
+Anti-harassment policy
+======================
+
+Harassment includes (but is not limited to) all of the following behaviors:
+
+- Offensive comments related to gender (including gender expression and identity), age, sexual orientation, disability, physical appearance, body size, race, and religion
+- Derogatory terminology including words commonly known to be slurs
+- Posting sexualized images or imagery in public spaces
+- Deliberate intimidation
+- Stalking
+- Posting others' personal information without explicit permission
+- Sustained disruption of talks or other events
+- Inappropriate physical contact
+- Unwelcome sexual attention
+
+Participants asked to stop any harassing behavior are expected to comply immediately.
+Sponsors are also subject to the anti-harassment policy. In particular, sponsors should
+not use sexualized images, activities, or other material. Meetup organizing staff and
+other volunteer organizers should not use sexualized attire or otherwise create a
+sexualized environment at community events.
+
+In addition to the behaviors outlined above, continuing to behave a certain way after you
+have been asked to stop also constitutes harassment, even if that behavior is not
+specifically outlined in this policy. It is considerate and respectful to stop doing
+something after you have been asked to stop, and all community members are expected to
+comply with such requests immediately.
+
+Policy violations
+=================
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by
+contacting `codeofconduct@ansible.com <mailto:codeofconduct@ansible.com>`_, to any channel
+operator in the community IRC channels, or to the local organizers of an event. Meetup
+organizers are encouraged to prominently display points of contact for reporting unacceptable
+behavior at local events.
+
+If a participant engages in harassing behavior, the meetup organizers may take any action
+they deem appropriate. These actions may include but are not limited to warning the
+offender, expelling the offender from the event, and barring the offender from future
+community events.
+
+Organizers will be happy to help participants contact security or local law enforcement,
+provide escorts to an alternate location, or otherwise assist those experiencing
+harassment to feel safe for the duration of the meetup. We value the safety and well-being
+of our community members and want everyone to feel welcome at our events, both online and
+offline.
+
+We expect all participants, organizers, speakers, and attendees to follow these policies at
+all of our event venues and event-related social events.
+
+The Ansible Community Code of Conduct is licensed under the Creative Commons
+Attribution-Share Alike 3.0 license. Our Code of Conduct was adapted from Codes of Conduct
+of other open source projects, including:
+
+* Contributor Covenant
+* Elastic
+* The Fedora Project
+* OpenStack
+* Puppet Labs
+* Ubuntu
diff --git a/docs/docsite/rst/community/communication.rst b/docs/docsite/rst/community/communication.rst
new file mode 100644
index 0000000000..2aaf1b2697
--- /dev/null
+++ b/docs/docsite/rst/community/communication.rst
@@ -0,0 +1,68 @@
+*************
+Communicating
+*************
+
+.. contents:: Topics
+
+Mailing List Information
+========================
+
+Ansible has several mailing lists.  Your first post to the mailing list will be moderated (to reduce spam), so please allow up to a day or so for your first post to appear.
+
+`Ansible Project List <https://groups.google.com/forum/#!forum/ansible-project>`_ is for sharing Ansible tips, answering questions, and general user discussion.
+
+`Ansible Development List <https://groups.google.com/forum/#!forum/ansible-devel>`_ is for learning how to develop on Ansible, asking about prospective feature design, or discussions about extending ansible or features in progress.
+
+`Ansible Announce list <https://groups.google.com/forum/#!forum/ansible-announce>`_ is a read-only list that shares information about new releases of Ansible, and also rare infrequent event information, such as announcements about an upcoming AnsibleFest, which is our official conference series.
+
+`Ansible Container List <https://groups.google.com/forum/#!forum/ansible-container>`_ is for users and developers of the Ansible Container project.
+
+`Ansible Lockdown List <https://groups.google.com/forum/#!forum/ansible-lockdown>`_ is for all things related to Ansible Lockdown projects, including DISA STIG automation and CIS Benchmarks.
+
+To subscribe to a group from a non-Google account, you can send an email to the subscription address requesting the subscription. For example: `ansible-devel+subscribe@googlegroups.com`
+
+IRC Channel
+===========
+
+Ansible has several IRC channels on Freenode (irc.freenode.net).
+
+General Channels
+----------------
+
+- ``#ansible`` - For general use questions and support.
+- ``#ansible-devel`` - For discussions on developer topics and code related to features/bugs.
+- ``#ansible-meeting`` - For public community meetings. We will generally announce these on one or more of the above mailing lists. See the `meeting schedule and agenda page <https://github.com/ansible/community/blob/master/meetings/README.md>`_
+- ``#ansible-notices`` - Mostly bot output from things like GitHub, etc.
+
+Working Group
+-------------
+
+- ``#ansible-aws`` - For discussions on Amazon Web Services.
+- ``#ansible-community`` - Channel for discussing Ansible Community related things.
+- ``#ansible-container`` - For discussions on Ansible Container.
+- ``#ansible-jboss`` - Channel for discussing JBoss and Ansible related things.
+- ``#ansible-network`` - Channel for discussing Network and Ansible related things.
+- ``#ansible-news`` - Channel for discussing Ansible Communication & News related things.
+- ``#ansible-vmware`` - For discussions on Ansible & VMware.
+- ``#ansible-windows`` - For discussions on Ansible & Windows.
+
+
+Language specific channels
+--------------------------
+
+- ``#ansible-es`` - Channel for Spanish speaking Ansible community.
+- ``#ansible-fr`` - Channel for French speaking Ansible community.
+
+
+IRC Meetings
+------------
+
+The Ansible community holds regular IRC meetings on various topics, and anyone who is interested is invited to
+participate. For more information about Ansible meetings, consult the `meeting schedule and agenda page <https://github.com/ansible/community/blob/master/meetings/README.md>`_.
+
+Tower Support Questions
+========================
+
+Ansible `Tower <https://ansible.com/tower>`_ is a UI, Server, and REST endpoint for Ansible.
+
+If you have a question about Ansible Tower, visit `Red Hat support <https://access.redhat.com/products/ansible-tower-red-hat/>`_ rather than using the IRC channel or the general project mailing list.
diff --git a/docs/docsite/rst/community/development_process.rst b/docs/docsite/rst/community/development_process.rst
new file mode 100644
index 0000000000..050d8c9b9c
--- /dev/null
+++ b/docs/docsite/rst/community/development_process.rst
@@ -0,0 +1,113 @@
+The Ansible Development Process
+===============================
+
+.. contents:: Topics
+
+This section discusses how the Ansible development and triage process works.
+
+Road Maps
+=========
+
+The Ansible Core team provides a road map for each upcoming release. These road maps can be found `here <http://docs.ansible.com/ansible/latest/roadmap/>`_.
+
+Pull Requests
+=============
+
+Ansible accepts code via **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.
+
+Because Ansible receives many pull requests, we use an automated process to help us through the process of reviewing and merging pull requests. That process is managed by **Ansibullbot**.
+
+Ansibullbot
+===========
+
+Overview
+--------
+
+`Ansibullbot`_ 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
+
+Community Maintainers
+---------------------
+
+Each module has at least one assigned maintainer, listed in a `maintainer's file`_:
+
+.. _Ansibullbot: https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md
+.. _maintainer's file: https://github.com/ansible/ansible/blob/devel/.github/BOTMETA.yml
+
+Some modules have no community maintainers assigned. In this case, the maintainer is listed as ``$team_ansible``. Ultimately, it’s our goal to have at least one community maintainer for every module.
+
+The maintainer’s job is to review PRs and decide whether that PR should be merged (``shipit``) or revised (``needs_revision``).
+
+The ultimate goal of any pull request is to reach **shipit** status, where the Core team then decides whether the PR is ready to be merged. Not every PR that reaches 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.
+
+
+
+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 Shippable 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. (Note: no longer used by the bot.)
+-  **needs_revision**: Waiting on the submitter to make changes.
+-  **shipit**: Waiting for final review by the core team for potential merge.
+
+Informational 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, etc).
+
+
+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.
diff --git a/docs/docsite/rst/community/how_can_I_help.rst b/docs/docsite/rst/community/how_can_I_help.rst
new file mode 100644
index 0000000000..27f899475a
--- /dev/null
+++ b/docs/docsite/rst/community/how_can_I_help.rst
@@ -0,0 +1,71 @@
+How To Help
+===========
+
+.. contents:: Topics
+
+There are many ways to help the Ansible project.
+
+Become a power user
+-------------------
+
+A great way to help the Ansible project is to become a power user:
+
+* Use Ansible everywhere you can
+* Take tutorials and classes
+* Read the `official documentation <http://docs.ansible.com/ansible/latest/index.html>`_
+* Study some of the `many excellent books <https://www.amazon.com/s/ref=nb_sb_ss_c_2_7?url=search-alias%3Dstripbooks&field-keywords=ansible&sprefix=ansible%2Caps%2C260>`_ about Ansible
+* `Get certified <https://www.ansible.com/training-certification>`_.
+
+When you become a power user, your ability and opportunities to help the Ansible project in other ways will multiply quickly.
+
+Ask and answer questions online
+-------------------------------
+
+There are many forums online where Ansible users ask and answer questions. Reach out and communicate with your fellow Ansible users. 
+
+You can find the official :ref:`Ansible communication channels <communication>`.
+
+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/ansible-meetup-organizer>`_.
+
+File and verify issues
+----------------------
+
+All software has bugs, and Ansible is no exception. When you find a bug, you can help tremendously by :ref:`telling us about it <reporting_bugs_and_features>`.
+
+
+If you should discover that the bug you're trying to file already exists in an issue, you can help by verifying the behavior of the reported bug with a comment in that issue, or by reporting any additional information.
+
+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've got a solution to a bug you've found in Ansible, or if you've got a new feature that you've written and would like to share with millions of Ansible users, read all about the `Ansible development process <http://docs.ansible.com/ansible/latest/community/development_process.rst>` 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/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.
+
+Become a module maintainer
+--------------------------
+
+Once you've learned about the development process and have contributed code to a particular module, we encourage you to become a maintainer of that module. There are hundreds of different modules in Ansible, 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>`.
+
+Join a working group
+--------------------
+
+Working groups are a way for Ansible community members to self-organize around particular topics of interest. We have working groups around various topics. To join or create a working group, please read the `Ansible working group guidelines <https://github.com/ansible/community/blob/master/WORKING-GROUPS.md>`_.
+
+
+Teach Ansible to others
+-----------------------
+
+We're working on a standardized Ansible workshop called `Lightbulb <https://github.com/ansible/lightbulb>`_ that can provide a good hands-on introduction to Ansible usage and concepts.
+
+Social media
+------------
+
+If you like Ansible and just want to spread the good word, feel free to share on your social media platform of choice, and let us know by using ``@ansible`` or ``#ansible``. We'll be looking for you.
diff --git a/docs/docsite/rst/community/index.rst b/docs/docsite/rst/community/index.rst
new file mode 100644
index 0000000000..78ee69c201
--- /dev/null
+++ b/docs/docsite/rst/community/index.rst
@@ -0,0 +1,26 @@
+*********************
+Community Information
+*********************
+
+Ansible Community Guide
+=======================
+
+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.
+
+To get started, select one of the following topics.
+
+
+.. toctree::
+   :maxdepth: 1
+
+   development_process
+   reporting_bugs_and_features
+   how_can_I_help
+   maintainers
+   communication
+   other_tools_and_programs
+
+
+
diff --git a/docs/docsite/rst/community/maintainers.rst b/docs/docsite/rst/community/maintainers.rst
new file mode 100644
index 0000000000..bb1541c31f
--- /dev/null
+++ b/docs/docsite/rst/community/maintainers.rst
@@ -0,0 +1,71 @@
+****************************
+Module Maintainer Guidelines
+****************************
+
+.. contents:: Topics
+
+Thank you for being a maintainer of one Ansible's community modules! This guide provides module maintainers an overview of their responsibilities, resources for additional information, and links to helpful tools.
+
+In addition to the information below, module maintainers should be familiar with:
+
+* :ref:`General Ansible community development practices <../community>`
+* Documentation on :ref:`module development <developing_modules.html>`
+
+
+Maintainer Responsibilities
+===========================
+
+When you contribute a new module to the [ansible/ansible](https://github.com/ansible/ansible) repository, you become the maintainer for that module once it has been merged. Maintainership empowers you with the authority to accept, reject, or request revisions to pull requests on your module -- but as they say, "with great power comes great responsibility."
+
+Maintainers of Ansible modules are expected to provide feedback, responses, or actions on pull requests or issues to the module(s) they maintain in a reasonably timely manner.
+
+It is also recommended that you occasionally revisit the [contribution guidelines](https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.md), as they are continually refined. Occasionally, you may be requested to update your module to move it closer to the general accepted standard requirements. We hope for this to be infrequent, and will always be a request with a fair amount of lead time (ie: not by tomorrow!).
+
+Finally, following the [ansible-devel](https://groups.google.com/forum/#!forum/ansible-devel) mailing list can be a great way to participate in the broader Ansible community, and a place where you can influence the overall direction, quality, and goals of Ansible and its modules. If you're not on this relatively low-volume list, please join us here: https://groups.google.com/forum/#!forum/ansible-devel
+
+The Ansible community hopes that you will find that maintaining your module is as rewarding for you as having the module is for the wider community.
+
+Pull Requests, Issues, and Workflow
+===================================
+
+Pull Requests
+-------------
+
+Module pull requests are located in the [main Ansible repository](https://github.com/ansible/ansible/pulls).
+
+Because of the high volume of pull requests, notification of PRs to specific modules are routed by an automated bot to the appropriate maintainer for handling. It is recommended that you set an appropriate notification process to receive notifications which mention your GitHub ID.
+
+Issues
+------
+
+Issues for modules, including bug reports, documentation bug reports, and feature requests, are tracked in the [ansible repository](https://github.com/ansible/ansible/issues).
+
+Issues for modules are routed to their maintainers via an automated process. This process is still being refined, and currently depends upon the issue creator to provide adequate details (specifically, providing the proper module name) in order to route it correctly. If you are a maintainer of a specific module, it is recommended that you periodically search module issues for issues which mention your module's name (or some variation on that name), as well as setting an appropriate notification process for receiving notification of mentions of your GitHub ID.
+
+PR Workflow
+-----------
+
+Automated routing of pull requests is handled by a tool called [Ansibot](https://github.com/ansible/ansibullbot). 
+
+Being moderately familiar with how the workflow behind the bot operates can be helpful to you, and -- should things go awry -- your feedback can be helpful to the folks that continually help Ansibullbot to evolve.
+
+A detailed explanation of the PR workflow can be seen here: https://github.com/ansible/community/blob/master/PR-FLOW.md
+
+Extras maintainers list
+-----------------------
+
+The full list of maintainers for modules is located here: https://github.com/ansible/ansibullbot/blob/master/MAINTAINERS.txt
+
+Changing Maintainership
+-----------------------
+
+Communities change over time, and no one maintains a module forever. If you'd like to propose an additional maintainer for your module, please submit a PR to the maintainers file with the Github username of the new maintainer.
+
+If you'd like to step down as a maintainer, please submit a PR to the maintainers file removing your Github ID from the module in question. If that would leave the module with no maintainers, put "ansible" as the maintainer.  This will indicate that the module is temporarily without a maintainer, and the Ansible community team will search for a new maintainer.
+
+Tools and other Resources
+-------------------------
+
+* https://ansible.sivel.net/pr/byfile.html -- a full list of all open Pull Requests, organized by file.
+* Ansibullbot: https://github.com/ansible/ansibullbot
+* Triage / pull request workflow and information, including definitions for Labels in GitHub: https://github.com/ansible/community/blob/master/PR-FLOW.md
diff --git a/docs/docsite/rst/community/other_tools_and_programs.rst b/docs/docsite/rst/community/other_tools_and_programs.rst
new file mode 100644
index 0000000000..e10f183346
--- /dev/null
+++ b/docs/docsite/rst/community/other_tools_and_programs.rst
@@ -0,0 +1,18 @@
+************************
+Other Tools And Programs
+************************
+
+The Ansible community provides several useful tools for working with the Ansible project. This is a list
+of some of the most popular of these tools.
+
+- `PR by File <https://ansible.sivel.net/pr/byfile.html>`_ shows a current list of all open pull requests by individual file. An essential tool for Ansible module maintainers.
+
+- `Ansible Lint <https://github.com/willthames/ansible-lint>`_ is a widely used, highly configurable best-practices linter for Ansible playbooks.
+
+- `Ansible Review <http://willthames.github.io/2016/06/28/announcing-ansible-review.html>`_ is an extension of Ansible Lint designed for code review.
+
+- `jctanner's Ansible Tools <https://github.com/jctanner/ansible-tools>`_ is a miscellaneous collection of useful helper scripts for Ansible development.
+
+- `Ansigenome <https://github.com/nickjj/ansigenome>`_ is a command line tool designed to help you manage your Ansible roles.
+
+- `Awesome Ansible <https://github.com/jdauphant/awesome-ansible>`_ is a collaboratively curated list of awesome Ansible resources.
diff --git a/docs/docsite/rst/community/reporting_bugs_and_features.rst b/docs/docsite/rst/community/reporting_bugs_and_features.rst
new file mode 100644
index 0000000000..c054a55163
--- /dev/null
+++ b/docs/docsite/rst/community/reporting_bugs_and_features.rst
@@ -0,0 +1,35 @@
+**************************************
+Reporting Bugs And Requesting Features
+**************************************
+
+.. contents:: Topics
+
+Reporting A Bug
+===============
+
+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 the Google Group and you will receive a prompt response.
+
+Ansible bugs should be reported to `github.com/ansible/ansible/issues <https://github.com/ansible/ansible/issues>`_ after
+signing up for a free GitHub account.  Before reporting a bug, please use the bug/issue search
+to see if the issue has already been reported. This is listed on the bottom of the docs page for any module.
+
+Knowing your Ansible version and the exact commands you are running, and what you expect, saves time and helps us help everyone with their issues more quickly. For that reason, we provide an issue template; please fill it out as completely and as accurately as possible.
+
+Do not use the issue tracker for "how do I do this" type questions.  These are great candidates for IRC or the mailing list instead where things are likely to be more of a discussion.
+
+To be respectful of reviewers' time and allow us to help everyone efficiently, please  provide minimal well-reduced and well-commented examples versus sharing your entire production playbook.  Include playbook snippets and output where possible.
+
+When sharing YAML in playbooks, formatting can be preserved by using `code blocks  <https://help.github.com/articles/creating-and-highlighting-code-blocks/>`_.
+
+For multiple-file content, we encourage use of gist.github.com.  Online pastebin content can expire, so it's nice to have things around for a longer term if they are referenced in a ticket.
+
+If you are not sure if something is a bug yet, you are welcome to ask about something on the mailing list or IRC first.
+
+As we are a very high volume project, if you determine that you do have a bug, please be sure to open the issue yourself to ensure we have a record of it. Don’t rely on someone else in the community to file the bug report for you.
+
+Requesting a feature
+====================
+
+The best way to get a feature into Ansible is to submit a pull request.
+
+The next best way of getting a feature into Ansible is to submit a proposal through the `Ansible proposal process  <https://github.com/ansible/proposals>` .
diff --git a/docs/docsite/rst/community/triage_process.rst b/docs/docsite/rst/community/triage_process.rst
new file mode 100644
index 0000000000..5634c8e0b8
--- /dev/null
+++ b/docs/docsite/rst/community/triage_process.rst
@@ -0,0 +1,8 @@
+**************
+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>`.