Greg DeKoenigsberg
2015-07-23 18:09:11 UTC
We've now completed a comprehensive review of every old pull request
in both Core and Extras repos. Each PR should now be in one of the
following states, represented by a label:
* community_review -- this means that a PR needs to be reviewed by the
community for potential inclusion. This is the default state for all
PRs for new modules, or for any PR to any module maintained by a
community member.
* core_review -- this means that a PR needs to be reviewed by the
Ansible core team. It's reserved for PRs to modules specifically owned
by the Ansible core team, or for PRs that require escalation for
whatever reason.
* needs_revision -- this means that a PR has been reviewed and found
in need of changes by the submitter.
* needs_rebase -- this means that a PR fails its merge test and must
therefore be rebased by the submitter.
* needs_info -- this means that it's unclear what state a PR is in,
and we need to follow up to figure out what state it should be in.
* priority_reviewed -- this means that a PR has been upvoted by its
reviewers and will be considered by the core team for immediate
inclusion.
* action_pending -- this is reserved for PRs that have been stalled
due to an inactive participant (no action in 30 days), and action is
about to be taken. If the PR is stuck in needs_revision, needs_rebase
or needs_info and there's no response within a week, the PR will be
closed as inactive. If the PR is stuck in community_review, and
there's no response from the reviewer within a week, the PR will be
reassigned to core_review and we will look for a new
maintainer/reviewer for the module.
We will continue to monitor PRs to ensure that each one is properly
tagged, and to make sure that our workflow is as effective as
possible. We will also be updating the contributor guidelines to
reflect this new policy.
This also brings us to some issues we are still working through:
* Module maintenance. We are now asking module authors to be
responsible for the maintenance of those modules over time, including
management of issues and pull requests that pertain to their modules.
Some module authors are not willing or able to perform this
maintenance. That's ok, and no one should feel obliged to own their
modules forever -- but we also want to have a policy by which we can
hand off the maintainership of modules to people who use them and care
about them. We're already seeing a number of unresponsive module
maintainers, so we will assign maintenance of these modules to the
core team while we work on our unresponsive maintainer process.
* Reviews of new modules. New modules continue to be a particular
challenge. We want to bring modules in as quickly as possible, but we
also want to ensure that modules continue to be of the highest
quality, and we've implemented the common "2 +1s, 0 -1s" policy for
acceptance of new modules. One possibility: weekly IRC sessions
explicitly for the review of new modules, with the intention of
working down the backlog from oldest to newest. The more hands we
have, the better; it's my hope that we can work through the backlog
quickly with a concerted effort. Of course, as we become more
successful, more modules will come in the door, so this will be an
ongoing process. Keep your eyes open for ideas and improvements here.
Comments to the above process welcome / actively encouraged. No
process is set in stone, and we're happy to iterate to improve this
process for everyone.
Finally, thanks to everyone for your continued patience as we work to
improve the throughput of one of the most active communities in the
entire open source world. It's inspiring to work with all of you.
--g
--
Greg DeKoenigsberg
Ansible Community Guy
Find out why SD Times named Ansible
their #1 Company to Watch in 2015:
http://sdtimes.com/companies-watch-2015/
in both Core and Extras repos. Each PR should now be in one of the
following states, represented by a label:
* community_review -- this means that a PR needs to be reviewed by the
community for potential inclusion. This is the default state for all
PRs for new modules, or for any PR to any module maintained by a
community member.
* core_review -- this means that a PR needs to be reviewed by the
Ansible core team. It's reserved for PRs to modules specifically owned
by the Ansible core team, or for PRs that require escalation for
whatever reason.
* needs_revision -- this means that a PR has been reviewed and found
in need of changes by the submitter.
* needs_rebase -- this means that a PR fails its merge test and must
therefore be rebased by the submitter.
* needs_info -- this means that it's unclear what state a PR is in,
and we need to follow up to figure out what state it should be in.
* priority_reviewed -- this means that a PR has been upvoted by its
reviewers and will be considered by the core team for immediate
inclusion.
* action_pending -- this is reserved for PRs that have been stalled
due to an inactive participant (no action in 30 days), and action is
about to be taken. If the PR is stuck in needs_revision, needs_rebase
or needs_info and there's no response within a week, the PR will be
closed as inactive. If the PR is stuck in community_review, and
there's no response from the reviewer within a week, the PR will be
reassigned to core_review and we will look for a new
maintainer/reviewer for the module.
We will continue to monitor PRs to ensure that each one is properly
tagged, and to make sure that our workflow is as effective as
possible. We will also be updating the contributor guidelines to
reflect this new policy.
This also brings us to some issues we are still working through:
* Module maintenance. We are now asking module authors to be
responsible for the maintenance of those modules over time, including
management of issues and pull requests that pertain to their modules.
Some module authors are not willing or able to perform this
maintenance. That's ok, and no one should feel obliged to own their
modules forever -- but we also want to have a policy by which we can
hand off the maintainership of modules to people who use them and care
about them. We're already seeing a number of unresponsive module
maintainers, so we will assign maintenance of these modules to the
core team while we work on our unresponsive maintainer process.
* Reviews of new modules. New modules continue to be a particular
challenge. We want to bring modules in as quickly as possible, but we
also want to ensure that modules continue to be of the highest
quality, and we've implemented the common "2 +1s, 0 -1s" policy for
acceptance of new modules. One possibility: weekly IRC sessions
explicitly for the review of new modules, with the intention of
working down the backlog from oldest to newest. The more hands we
have, the better; it's my hope that we can work through the backlog
quickly with a concerted effort. Of course, as we become more
successful, more modules will come in the door, so this will be an
ongoing process. Keep your eyes open for ideas and improvements here.
Comments to the above process welcome / actively encouraged. No
process is set in stone, and we're happy to iterate to improve this
process for everyone.
Finally, thanks to everyone for your continued patience as we work to
improve the throughput of one of the most active communities in the
entire open source world. It's inspiring to work with all of you.
--g
--
Greg DeKoenigsberg
Ansible Community Guy
Find out why SD Times named Ansible
their #1 Company to Watch in 2015:
http://sdtimes.com/companies-watch-2015/
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAM1FbhGST059axDXyx2qdPK7%3DWA11HnmJdk%3DrCk%3DC4bW6L29Tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+***@googlegroups.com.
To post to this group, send email to ansible-***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAM1FbhGST059axDXyx2qdPK7%3DWA11HnmJdk%3DrCk%3DC4bW6L29Tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.