Hi all. Wanted to give a quick update on our initiatives around improving the PR pipeline for ansible-modules-extras.
To review: we recently decided on two major policy changes. (1) All PRs to existing modules are merged with +1 from the module owner (which implies that module owners can make changes without further approval; please, module owners, be careful with this power.) (2) All new modules require two +1s from existing module maintainers to be included. To support this policy change, we went through and added the Github IDs of all module owners as metadata within each module file. I spent the last week learning the Github API well enough to scrape this data well enough to give myself some rudimentary tools to help speed up merges (I'll be checking some of this stuff in soon). Over the past day, I've done a comprehensive review of all open PRs against existing modules. Where auto-merge was not possible, I asked submitters to rebase; where auto-merge was possible, I asked reviewers to give +1 if review indicates the PR is good. We've already closed a number of outstanding PRs this way, so to both committers and reviewers, a big thank you. Your work is much appreciated. Which brings us to the stickier subject: new modules. The backlog is, uh, large; we have almost 100 PRs for new modules awaiting evaluation for inclusion into Extras -- which is 2/3rd of our current open PRs against Extras. It's time to solicit reviews for new modules aggressively. To do this, we'll need a couple of things first: 1. A list of reviewers. By policy, a new module needs +1 from two different reviewers (note that any Ansible employee gets two votes, prerogative of upstream). Current reviewers are "module owners", so I'll put together a list of those people in a file called REVIEWERS.md. I am aware that this is a bit of a blunt object approach, but it's a starting point. We can always remove/add reviewers as we see fit, based on sensible new criteria. 2. Criteria for inclusion. We want to take care to be opinionated about the right things, so we'll put together some review guidelines that any reviewer can follow. We don't want to judge on content; we want to judge on the ability to make an Ansible module that works as expected (idempotent, testable, adheres to style guidelines, etc.) Getting the first thing done should be quick; getting the second done might take a while, so that will be our next focus. I will work with the team to nail down these guidelines as quickly as we can, so that we can start delegating more responsibility to our community asap. Thanks to everyone for your support and patience as we continue our work to hack down our backlog and grow our contributor base. --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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAM1FbhGyrSY4e%2BpJcq3AnQA%2B_xXGP_SY8_F1gWpKQFgxG4qeVA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
