ansible/community.general
1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00
Code Releases Activity

Edit pass for relocated community documentation. (#28368)

Browse source 
* Edit pass for relocated community documentation.

* Updated info on Ansibullbot

Fixed improper link syntax
Change links to point to new documents
Changed Ansibot to Ansibullbot
Clarified workflow
Change formatting on commans and tags

* Update communication.rst

Add Contents
Use correct headings

* Update communication.rst

* Topics, remove whitespace, codeofconduct

* Formatting

* Correct heading

* Update maintainers.rst

* Minor edits and a request for more info

* Removed some hard-to-localize wording.

* Removed incomplete sentence

* Minor edits per review
This commit is contained in:
scottb 2017-08-31 12:14:35 -07:00 committed by GitHub
parent 84295e6124
commit b146e17733
9 changed files with 156 additions and 182 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
docs/docsite/rst/community/code_of_conduct.rst
View file

@ -1,5 +1,8 @@
*************************
Community Code of Conduct Community Code of Conduct
========================= *************************
.. contents:: Topics
Every community can be strengthened by a diverse variety of viewpoints, insights, Every community can be strengthened by a diverse variety of viewpoints, insights,
opinions, skillsets, and skill levels. However, with diversity comes the potential for opinions, skillsets, and skill levels. However, with diversity comes the potential for
@ -80,7 +83,8 @@ documentation thoroughly. We are happy to answer questions, provide strategic gu
and suggest effective workflows, but we are not here to do your job for you. and suggest effective workflows, but we are not here to do your job for you.
Anti-harassment policy Anti-harassment policy
---------------------- ======================
Harassment includes (but is not limited to) all of the following behaviors: 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 - Offensive comments related to gender (including gender expression and identity), age, sexual orientation, disability, physical appearance, body size, race, and religion
@ -106,7 +110,8 @@ something after you have been asked to stop, and all community members are expec
comply with such requests immediately. comply with such requests immediately.
Policy violations Policy violations
----------------- =================
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by
contacting `codeofconduct@ansible.com <mailto:codeofconduct@ansible.com>`_, to any channel 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 operator in the community IRC channels, or to the local organizers of an event. Meetup

49
docs/docsite/rst/community/communication.rst
View file

@ -1,47 +1,68 @@
*************
Communicating Communicating
============= *************
.. contents:: Topics
Mailing List Information Mailing List Information
------------------------ ========================
Ansible has several mailing lists. Your first post to the mailing list will be moderated (to reduce spam), so please allow a day or less for your first post. 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 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 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 AnsibleFest coming up, which is our official conference series. `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 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. `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 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 IRC Channel
----------- ===========
Ansible has several IRC channels on Freenode (irc.freenode.net): Ansible has several IRC channels on Freenode (irc.freenode.net).
General Channels
----------------
- ``#ansible`` - For general use questions and support. - ``#ansible`` - For general use questions and support.
- ``#ansible-devel`` - For discussions on developer topics and code related to features/bugs. - ``#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-aws`` - For discussions on Amazon Web Services.
- ``#ansible-community`` - Channel for discussing Ansible Community related things.
- ``#ansible-container`` - For discussions on Ansible Container. - ``#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-vmware`` - For discussions on Ansible & VMware.
- ``#ansible-windows`` - For discussions on Ansible & Windows. - ``#ansible-windows`` - For discussions on Ansible & Windows.
- ``#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.
Language specific channels
--------------------------
- ``#ansible-es`` - Channel for Spanish speaking Ansible community.
- ``#ansible-fr`` - Channel for French speaking Ansible community.
IRC Meetings IRC Meetings
------------ ------------
The Ansible community holds regular IRC meetings on various topics, and anyone who is interested is invited to 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>`_. 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 Tower Support Questions
----------------------- ========================
Ansible `Tower <https://ansible.com/tower>`_ is a UI, Server, and REST endpoint for Ansible, produced by Ansible, Inc. Ansible `Tower <https://ansible.com/tower>`_ is a UI, Server, and REST endpoint for Ansible.
If you have a question about 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. 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.

188
docs/docsite/rst/community/development_process.rst
View file

@ -1,177 +1,113 @@
The Ansible Development Process The Ansible Development Process
=============================== ===============================
.. contents:: Topics
This section discusses how the Ansible development and triage process works. This section discusses how the Ansible development and triage process works.
Roadmaps Road Maps
======== =========
The Ansible Core team provides a roadmap for each upcoming release. These roadmaps can be found `here <http://docs.ansible.com/ansible/latest/roadmap/>`. 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 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. 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 the Ansibot. 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**.
The Ansibot Ansibullbot
=========== ===========
Overview Overview
-------- --------
The `Ansibot`_ serves many functions: \* Responds quickly `Ansibullbot`_ serves many functions:
to PR submitters to thank them for submitting their PR; \* Identifies
the community maintainer responsible for reviewing PRs for any files - Responds quickly to PR submitters to thank them for submitting their PR
affected; \* Tracks the current status of PRs; \* Pings responsible - Identifies the community maintainer responsible for reviewing PRs for any files affected
parties to remind them of any PR actions that they may be responsible - Tracks the current status of PRs
for; \* Provides maintainers with the ability to move PRs through our - Pings responsible parties to remind them of any PR actions for which they may be responsible
workflow; \* Identifies PRs abandoned by their submitters so that we can - Provides maintainers with the ability to move PRs through the workflow
close them; \* Identifies modules abandoned by their maintainers so that - Identifies PRs abandoned by their submitters so that we can close them
we can find new maintainers. - Identifies modules abandoned by their maintainers so that we can find new maintainers
Community Maintainers Community Maintainers
--------------------- ---------------------
Each module in Core and Extras has at least one assigned maintainer, Each module has at least one assigned maintainer, listed in a `maintainer's file`_:
listed in two maintainers files: one for `Core`_ and one for `Extras`_.
Some modules have no community maintainers assigned. In this case, the .. _Ansibullbot: https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md
maintainer is listed as “ansible”. Ultimately, it’s our goal to have at .. _maintainer's file: https://github.com/ansible/ansible/blob/devel/.github/BOTMETA.yml
least one community maintainer for every module.
The maintainer’s job is to review PRs and decide whether that PR should 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.
be merged (“shipit!”) or revised (“needs\_revision”).
The ultimate goal of any Pull Request is to reach “shipit” status, where The maintainer’s job is to review PRs and decide whether that PR should be merged (``shipit``) or revised (``needs_revision``).
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.
.. _Ansibot: https://github.com/ansible/ansibullbot/blob/master/triage.py 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.
.. _Core: https://github.com/ansible/ansibullbot/blob/master/MAINTAINERS-CORE.txt
.. _Extras: https://github.com/ansible/ansibullbot/blob/master/MAINTAINERS-CORE.txt
Some modules have no community maintainers assigned. In this case, the
maintainer is listed as “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 Workflow
-------- --------
The triage bot runs every six hours and examines every open PR in both 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:
core and extras repositories, and enforces state roughly according to
the following workflow:
- If a PR has no workflow labels, it’s considered “new”. Files in the - 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.)
PR are identified, and the maintainers of those files are pinged by - If the module maintainer is not ``$team_ansible``, the pull request then goes into the **community_review** state.
the bot, along with instructions on how to review the PR. (Note: - If the module maintainer is ``$team_ansible``, the pull request then goes into the **core_review** state (and probably sits for a while).
sometimes we strip labels from a PR to “reboot” this process.) - If the pull request is in **community_review** and has received comments from the maintainer:
- If the module maintainer is not “ansible”, the PR then goes into the
“community\_review” state. - If the maintainer says ``shipit``, the pull request is labeled **shipit**, whereupon the Core team assesses it for final merge.
- If the module maintainer is “ansible”, the PR then goes into the - If the maintainer says ``needs_info``, the pull request is labeled **needs_info** and the submitter is asked for more info.
“core\_review” state (and probably sits for a while). - If the maintainer says **needs_revision**, the pull request is labeled **needs_revision** and the submitter is asked to fix some things.
- If the PR is in “community\_review” and has received comments from
the maintainer: - 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 maintainer says “shipit”, the PR is labeled “shipit”, - If the pull request is labeled **needs_revision** or **needs_info** and the submitter has not responded lately:
whereupon the Core team assesses it for final merge.
- If the maintainer says “needs\_info”, the PR is labeled “needs\_info” - 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.
and the submitter is asked for more info. - If the submitter responds at all, the clock is reset.
- If the maintainer says “needs\_revision”, the PR is labeled - If the pull request is labeled **community_review** and the reviewer has not responded lately:
“needs\_revision” and the submitter is asked to fix some things.
- If the PR is in “needs\_revision/needs\_info” and has received - 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.
comments from the submitter: - 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.
- If the submitter says “ready\_for\_review”, the PR is put back into
community\_review/core\_review and the maintainer is notified that
the PR is ready to be reviewed again.
- If the PR is in “needs\_revision/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 then may be
closed two weeks after that.
- If the submitter responds at all, the clock is reset.
- If the PR is in “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 “ansible” / core\_review, or often the submitter of the
PR is asked to step up as a maintainer.
- If Travis fails, or if the code is not mergable, the PR 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. There are corner cases and frequent refinements, but this is the workflow in general.
PR Labels PR Labels
--------- ---------
There are two types of PR Labels generally: *workflow labels* and There are two types of PR Labels generally: *workflow labels* and *information labels*.
*information labels*.
Workflow Labels Workflow Labels
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
- **community\_review**: Pull requests for modules that are currently - **community_review**: Pull requests for modules that are currently awaiting review by their maintainers in the Ansible community.
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.
- **core\_review**: Pull requests for modules that are currently - **needs_info**: Waiting on info from the submitter.
awaiting review by their maintainers on the Ansible Core team. - **needs_rebase**: Waiting on the submitter to rebase. (Note: no longer used by the bot.)
- **needs\_info**: Waiting on info from the submitter. - **needs_revision**: Waiting on the submitter to make changes.
- **needs\_rebase**: Waiting on the submitter to rebase. (Note: no - **shipit**: Waiting for final review by the core team for potential merge.
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 Informational Labels
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
- **backport**: this is applied automatically if the PR is requested - **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``.
against any branch that is not devel. The bot immediately assigns the - **bugfix_pull_request**: applied by the bot based on the templatized description of the PR.
labels “backport” and “core\_review”. - **cloud**: applied by the bot based on the paths of the modified files.
- **bugfix\_pull\_request**: applied by the bot based on the - **docs_pull_request**: applied by the bot based on the templatized description of the PR.
templatized description of the PR. - **easyfix**: applied manually, inconsistently used but sometimes useful.
- **cloud**: applied by the bot based on the paths of the modified - **feature_pull_request**: applied by the bot based on the templatized description of the PR.
files. - **networking**: applied by the bot based on the paths of the modified files.
- **docs\_pull\_request**: applied by the bot based on the templatized - **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**.
description of the PR. - **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).
- **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; now, 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”.
- **P1 - P5**: deprecated for modules because they were wildly
inconsistent and not useful. The bot now strips these.
- **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 Special Labels
~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
- **new\_plugin**: this is for new modules or plugins that are not yet - **new_plugin**: this is for new modules or plugins that are not yet in Ansible.
in Ansible. **Note: this kicks off a completely separate process, and
frankly it doesn’t work very well at present. We’re working our best **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.
to improve this process.**

33
docs/docsite/rst/community/how_can_I_help.rst
View file

@ -1,33 +1,42 @@
How To Help How To Help
=========== ===========
There are many ways to help the Ansible project. .. contents:: Topics
There are many ways to help the Ansible project.
Become a power user 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>` and 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>`. 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. 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 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. Ask good questions, and give good answers. 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 Ansible communication channels `here <http://docs.ansible.com/ansible/latest/community/communication.html>`. You can find the official :ref:`Ansible communication channels <communication>`.
Participate in your local meetup 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. 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>`. 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 File and verify issues
---------------------- ----------------------
All software has bugs, and Ansible is no exception. When you find a bug, you can help tremendously by `telling us about it <http://docs.ansible.com/ansible/latest/community/reporting_bugs_and_features.rst>`. 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. 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.
@ -36,27 +45,27 @@ 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. 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. 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 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. 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 `module maintainer guidelines <http://docs.ansible.com/ansible/latest/community/maintainers.rst>`. To learn more about the responsibilities of being an Ansible module maintainer, please read our :ref:`module maintainer guidelines <maintainers>`.
Join a working group 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>`. 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 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. 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 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. 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.

2
docs/docsite/rst/community/index.rst
View file

@ -7,7 +7,7 @@ Ansible Community Guide
Welcome to the 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. 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. To get started, select one of the following topics.

14
docs/docsite/rst/community/maintainers.rst
View file

@ -1,12 +1,16 @@
****************************
Module Maintainer Guidelines 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. 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: In addition to the information below, module maintainers should be familiar with:
* General Ansible community development practices (http://docs.ansible.com/ansible/community.html)
* Documentation on module development (http://docs.ansible.com/ansible/developing_modules.html) * :ref:`General Ansible community development practices <../community>`
* Any namespace-specific module guidelines (identified as GUIDELINES.md in the appropriate file tree). * Documentation on :ref:`module development <developing_modules.html>`
Maintainer Responsibilities Maintainer Responsibilities
=========================== ===========================
@ -41,7 +45,7 @@ Issues for modules are routed to their maintainers via an automated process. Thi
PR Workflow PR Workflow
----------- -----------
Automated routing of pull requests is handled by a tool called [Ansibot](https://github.com/ansible/ansibullbot). (You could say that he moooo-ves things around.) 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. 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.

21
docs/docsite/rst/community/other_tools_and_programs.rst
View file

@ -1,23 +1,18 @@
************************
Other Tools And Programs Other Tools And Programs
======================== ************************
The Ansible community provides several useful tools for working with the Ansible project. This is a list 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. 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 - `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.
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 - `Ansible Lint <https://github.com/willthames/ansible-lint>`_ is a widely used, highly configurable best-practices linter for Ansible playbooks.
linter for Ansible playbooks.
- `Ansible Review <http://willthames.github.io/2016/06/28/announcing-ansible-review.html>` is an extension of - `Ansible Review <http://willthames.github.io/2016/06/28/announcing-ansible-review.html>`_ is an extension of Ansible Lint designed for code review.
Ansible Lint designed for code review.
- `jctanner's Ansible Tools <https://github.com/jctanner/ansible-tools>` is a miscellaneous collection of - `jctanner's Ansible Tools <https://github.com/jctanner/ansible-tools>`_ is a miscellaneous collection of useful helper scripts for Ansible development.
useful helper scripts for Ansible development.
- `Ansigenome <https://github.com/nickjj/ansigenome>` is a command line tool designed to help you manage - `Ansigenome <https://github.com/nickjj/ansigenome>`_ is a command line tool designed to help you manage your Ansible roles.
your Ansible roles.
- `Awesome Ansible <https://github.com/jdauphant/awesome-ansible>` is a collaboratively curated list of - `Awesome Ansible <https://github.com/jdauphant/awesome-ansible>`_ is a collaboratively curated list of awesome Ansible resources.
awesome Ansible resources.

15
docs/docsite/rst/community/reporting_bugs_and_features.rst
View file

@ -1,8 +1,11 @@
**************************************
Reporting Bugs And Requesting Features Reporting Bugs And Requesting Features
====================================== **************************************
I'd Like To Report A Bug .. 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 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.
@ -10,7 +13,7 @@ Ansible bugs should be reported to `github.com/ansible/ansible/issues <https://g
signing up for a free GitHub account. Before reporting a bug, please use the bug/issue search 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. 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. 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. 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.
@ -20,12 +23,12 @@ When sharing YAML in playbooks, formatting can be preserved by using `code block
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. 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. 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. 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 Requesting a feature
-------------------- ====================
The best way to get a feature into Ansible is to submit a pull request. The best way to get a feature into Ansible is to submit a pull request.

5
docs/docsite/rst/community/triage_process.rst
View file

@ -1,7 +1,8 @@
**************
Triage Process 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. 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 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>`. Issue Guide <https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md>`.