mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Edit pass for relocated community documentation. (#28368)
* 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
GitHub
parent
84295e6124
commit
b146e17733
9 changed files with 156 additions and 182 deletions
|
|
@ -1,5 +1,8 @@
|
|||
*************************
|
||||
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
|
||||
|
|
@ -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.
|
||||
|
||||
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
|
||||
|
|
@ -106,7 +110,8 @@ something after you have been asked to stop, and all community members are expec
|
|||
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
|
||||
|
|
|
|||
|
|
@ -1,47 +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 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 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 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
|
||||
-----------
|
||||
===========
|
||||
|
||||
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-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.
|
||||
- ``#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
|
||||
------------
|
||||
|
||||
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>`_.
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,177 +1,113 @@
|
|||
The Ansible Development Process
|
||||
===============================
|
||||
|
||||
.. contents:: Topics
|
||||
|
||||
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
|
||||
=============
|
||||
|
||||
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
|
||||
--------
|
||||
|
||||
The `Ansibot`_ 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 that they may be responsible
|
||||
for; \* Provides maintainers with the ability to move PRs through our
|
||||
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.
|
||||
`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 in Core and Extras has at least one assigned maintainer,
|
||||
listed in two maintainers files: one for `Core`_ and one for `Extras`_.
|
||||
Each module has at least one assigned maintainer, listed in a `maintainer's file`_:
|
||||
|
||||
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.
|
||||
.. _Ansibullbot: https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md
|
||||
.. _maintainer's file: https://github.com/ansible/ansible/blob/devel/.github/BOTMETA.yml
|
||||
|
||||
The maintainer’s job is to review PRs and decide whether that PR should
|
||||
be merged (“shipit!”) or revised (“needs\_revision”).
|
||||
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 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.
|
||||
The maintainer’s job is to review PRs and decide whether that PR should be merged (``shipit``) or revised (``needs_revision``).
|
||||
|
||||
.. _Ansibot: https://github.com/ansible/ansibullbot/blob/master/triage.py
|
||||
.. _Core: https://github.com/ansible/ansibullbot/blob/master/MAINTAINERS-CORE.txt
|
||||
.. _Extras: https://github.com/ansible/ansibullbot/blob/master/MAINTAINERS-CORE.txt
|
||||
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.
|
||||
|
||||
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
|
||||
--------
|
||||
|
||||
The triage bot runs every six hours and examines every open PR in both
|
||||
core and extras repositories, and enforces state roughly according to
|
||||
the following 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 PR has no workflow labels, it’s considered “new”. Files in the
|
||||
PR are identified, and the maintainers of those files are pinged by
|
||||
the bot, along with instructions on how to review the PR. (Note:
|
||||
sometimes we strip labels from a PR to “reboot” this process.)
|
||||
- If the module maintainer is not “ansible”, the PR then goes into the
|
||||
“community\_review” state.
|
||||
- If the module maintainer is “ansible”, the PR then goes into the
|
||||
“core\_review” state (and probably sits for a while).
|
||||
- If the PR is in “community\_review” and has received comments from
|
||||
the maintainer:
|
||||
- If the maintainer says “shipit”, the PR is labeled “shipit”,
|
||||
whereupon the Core team assesses it for final merge.
|
||||
- If the maintainer says “needs\_info”, the PR is labeled “needs\_info”
|
||||
and the submitter is asked for more info.
|
||||
- If the maintainer says “needs\_revision”, the PR is labeled
|
||||
“needs\_revision” and the submitter is asked to fix some things.
|
||||
- If the PR is in “needs\_revision/needs\_info” and has received
|
||||
comments from the submitter:
|
||||
- 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.
|
||||
- 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.
|
||||
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*.
|
||||
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.
|
||||
- **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; 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).
|
||||
- **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: this 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.**
|
||||
- **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.
|
||||
|
|
|
|||
|
|
@ -1,33 +1,42 @@
|
|||
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
|
||||
-------------------
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
--------------------------------
|
||||
|
||||
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
|
||||
----------------------
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
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
|
||||
--------------------------
|
||||
|
||||
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
|
||||
--------------------
|
||||
|
||||
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
|
||||
-----------------------
|
||||
|
||||
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
|
||||
------------
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,16 @@
|
|||
****************************
|
||||
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:
|
||||
* General Ansible community development practices (http://docs.ansible.com/ansible/community.html)
|
||||
* Documentation on module development (http://docs.ansible.com/ansible/developing_modules.html)
|
||||
* Any namespace-specific module guidelines (identified as GUIDELINES.md in the appropriate file tree).
|
||||
|
||||
* :ref:`General Ansible community development practices <../community>`
|
||||
* Documentation on :ref:`module development <developing_modules.html>`
|
||||
|
||||
|
||||
Maintainer Responsibilities
|
||||
===========================
|
||||
|
|
@ -41,7 +45,7 @@ Issues for modules are routed to their maintainers via an automated process. Thi
|
|||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,23 +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.
|
||||
- `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 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.
|
||||
- `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.
|
||||
- `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.
|
||||
- `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.
|
||||
- `Awesome Ansible <https://github.com/jdauphant/awesome-ansible>`_ is a collaboratively curated list of awesome Ansible resources.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
**************************************
|
||||
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.
|
||||
|
||||
|
|
@ -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
|
||||
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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
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.
|
||||
|
||||
Requesting a feature
|
||||
--------------------
|
||||
====================
|
||||
|
||||
The best way to get a feature into Ansible is to submit a pull request.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +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
|
||||
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>`.
|
||||
|
|
|
|||
Loading…
Reference in a new issue