Thanks for your work, Greg. Happy to see progress in this area :) On Tuesday, 2 June 2015 00:47:18 UTC+10, Greg DeKoenigsberg wrote: > > 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/b8e409db-0064-416a-8d69-48d3c46432d3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
