# Extras triage proposal **URL:** \ **Category:** Ansible Developer\ **Created:** [April 21, 2015, 5:47pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041 "2015-04-21T17:47:55Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Greg\_DeKoenigsberg1](https://avatars.discourse-cdn.com/v4/letter/g/838e76/32.png) [@Greg\_DeKoenigsberg1](https://forum.ansible.com/u/Greg_DeKoenigsberg1)\ **Post date:** [April 21, 2015, 5:47pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/1 "2015-04-21T17:47:55Z")
Hi all. Starting to think about ways to open up the contribution process a little bit, while maintaining a high level of code quality. The purpose of splitting out modules originally into Core and Extras was to create a distinction between "Ansible Supported Modules" and "Community Supported Modules". As we grow, the set of modules in Extras should grow more quickly than elsewhere. Which also means that we'll definitely need some help maintaining these modules. So here's a simple proposal. Feedback welcome. \* Build a community team of triagers -- people who know Ansible modules well enough to assess PRs and judge whether they're good. \* Give this team of triagers authority to upvote Extras PRs. \* Two +1s from triagers, on any Extras PR, means that an Ansible developer can merge that PR immediately. There's a lot of stuff we \*could\* do, all the way from triaging to simply providing direct commit access to a bunch of folks. I'm hoping we can start with some small but impactful changes to test the waters a bit. Thoughts? --g ---
**Author:** ![Doug\_Luce](https://avatars.discourse-cdn.com/v4/letter/d/cc9497/32.png) [@Doug\_Luce](https://forum.ansible.com/u/Doug_Luce)\ **Post date:** [April 21, 2015, 7:44pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/2 "2015-04-21T19:44:43Z")
Not just for extras, core clearly needs some love, too. Actively encourage anyone to review a PR. Request a few lines justifying a +1 in specific terms:    - How's is this like/unlike similar modules?    - What were the results of testing it yourself?    - What changes would be good to add post-merge? Developers can ignore PR's until there's at least a couple of +1's with accompanying text. Encourage PR authors to solicit reviews from good people. If the original author doesn't respond to the last comment within a couple of weeks, close with "please reopen this after responding to the comments on it." Doug ---
**Author:** ![Greg\_DeKoenigsberg1](https://avatars.discourse-cdn.com/v4/letter/g/838e76/32.png) [@Greg\_DeKoenigsberg1](https://forum.ansible.com/u/Greg_DeKoenigsberg1)\ **Post date:** [April 21, 2015, 7:50pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/3 "2015-04-21T19:50:53Z")
> Not just for extras, core clearly needs some love, too. I agree, but the bar for core needs to be higher. We can use extras to figure out what works well and what doesn't. We can, of course, encourage these kinds of reviews in core too -- but they wouldn't lead to an automatic merge, maybe. > Actively encourage anyone to review a PR. Request a few lines > justifying a +1 in specific terms: > >   - How's is this like/unlike similar modules? >   - What were the results of testing it yourself? >   - What changes would be good to add post-merge? > > Developers can ignore PR's until there's at least a couple of +1's > with accompanying text. Encourage PR authors to solicit reviews from > good people. The goal is definitely to encourage reviewing as a standard practice, and to move well-reviewed PRs to the front of the queue in all cases. > If the original author doesn't respond to the last comment within a > couple of weeks, close with "please reopen this after responding to > the comments on it." > Doug I'm ok with this, but some might not be. 🙂 --g ---
**Author:** ![Doug\_Luce](https://avatars.discourse-cdn.com/v4/letter/d/cc9497/32.png) [@Doug\_Luce](https://forum.ansible.com/u/Doug_Luce)\ **Post date:** [April 21, 2015, 8:36pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/4 "2015-04-21T20:36:28Z")
I'd have an "unlikely to get merged without a couple good reviews" policy in lieu of automatic merge. Devs with write access remain the final arbiters but have much less work to do. Just read a couple of good capsule reviews before making a decision. Formally delegating/authorizing community members would be a lot of work and carry the risk of admitting unsuitable members and passing up on excellent ones. Doug ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [April 21, 2015, 9:55pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/5 "2015-04-21T21:55:04Z")
I would LOVE to see all tickets with reviews/testing by the community, it would make our job a lot easier and get tickets merged much faster. Aside from a few 'high use' modules, this does not happen, when it does those PRs do get merged much faster. Part of this modules-extra approach is trying to make this a more common occurrence. We have a huge backlog and we are just looking for ways to not let PRs rot and address the needs of the community. We are happy to consider any ideas that will help us with this. Changing the policy to 'not merge w/o any reviews' will definitely make MY life easier, but I don't think this will help the project or the community. ---
**Author:** ![Doug\_Luce](https://avatars.discourse-cdn.com/v4/letter/d/cc9497/32.png) [@Doug\_Luce](https://forum.ansible.com/u/Doug_Luce)\ **Post date:** [April 21, 2015, 10:03pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/6 "2015-04-21T22:03:08Z")
When an Ansible dev merges a review, give the good capsule reviewers one point each. Tally these on a prominent scoreboard. Top reviewers for each release are immortalized in the release announcement. The policy is better as "reviews will fast-track the merge" rather than "no reviews == no merge." Doug ---
**Author:** ![mcv21](https://avatars.discourse-cdn.com/v4/letter/m/7bcc69/32.png) [@mcv21](https://forum.ansible.com/u/mcv21)\ **Post date:** [April 22, 2015, 9:22am UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/7 "2015-04-22T09:22:02Z")
As the original author of an -extras module, it would be nice if I could be notified of issues in "my" module; more generally to be able to say I'd like emails about issues in some set of modules that I feel I might be able to help with. I don't want to see every -extras issue, but having to remember to scan github for new issues is, I observe, something I'm not very good at. Regards, Matthew ---
**Author:** ![Toshio\_Kuratomi](https://avatars.discourse-cdn.com/v4/letter/t/41988e/32.png) [@Toshio\_Kuratomi](https://forum.ansible.com/u/Toshio_Kuratomi)\ **Post date:** [April 22, 2015, 1:24pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/8 "2015-04-22T13:24:04Z")
I agree. github doesn't have an easy way to automatically cc people on a subset of the repository though. So we'll have to work out some procedure to do that manually. Maybe we could leverage github Teams? Create a team with the name of the module (or the next category up as in the documentation categories) and then whenever we get a bug report, always \cc @ansible/team-module as part of triage. The module author is put in the team automatically. Figure out some loose policy to add other people as well. -Toshio ---
**Author:** ![Greg\_DeKoenigsberg1](https://avatars.discourse-cdn.com/v4/letter/g/838e76/32.png) [@Greg\_DeKoenigsberg1](https://forum.ansible.com/u/Greg_DeKoenigsberg1)\ **Post date:** [April 22, 2015, 1:31pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/9 "2015-04-22T13:31:04Z")
The problem with Teams is that it's not granular enough -- afaict, you can't assign more granular permissions than "the entire repo level". Which means that people who are tracking extras still have to track the whole repo and not just their own stuff. Maybe it's possible to use your mail reader to filter by Subject, though, depending -- would need to play with the idea. We also need to discuss the idea of "extras modules creators being able to fast-track a push." Theoretically, the creator of the module should know best whether patches should be applied, right? --g ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [April 22, 2015, 1:52pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/10 "2015-04-22T13:52:13Z")
I actually have an app that I wrote that helps notify me, specifically created to keep track of modules and issues important to me: [https://github.com/sivel/github-notify](https://github.com/sivel/github-notify) Additionally I also have the following which is in use by the core team and a few others: [http://ansible.sivel.net/](http://ansible.sivel.net/) ---
**Author:** ![Greg\_DeKoenigsberg1](https://avatars.discourse-cdn.com/v4/letter/g/838e76/32.png) [@Greg\_DeKoenigsberg1](https://forum.ansible.com/u/Greg_DeKoenigsberg1)\ **Post date:** [April 22, 2015, 2:38pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/11 "2015-04-22T14:38:55Z")
> I actually have an app that I wrote that helps notify me, specifically > created to keep track of modules and issues important to me: > > [https://github.com/sivel/github-notify](https://github.com/sivel/github-notify) Ah. Well, there we are; this is exactly what I was thinking. So it should come as no surprise that it already exists. 🙂 > Additionally I also have the following which is in use by the core team and > a few others: [http://ansible.sivel.net/](http://ansible.sivel.net/) Also useful. Some of these files have a lot of PRs open against them... ---
**Author:** ![Rene\_Moser](https://avatars.discourse-cdn.com/v4/letter/r/7bcc69/32.png) [@Rene\_Moser](https://forum.ansible.com/u/Rene_Moser)\ **Post date:** [April 26, 2015, 9:39pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/12 "2015-04-26T21:39:49Z")
Hi Greg I really love the idea and your proposal! It is basically what I ask for few months ago. So I definitely would like to try this out on extras! Maybe technically a few thoughts: Along with the “author” field in the modules, I thought about adding a “maintainers” list to the modules (with the github account names and/or email addresses), starting with the 3rd party committers of the modules, giving them opt-out. So any maintainer gets an email on issues, PRs and commits related to that module and can give +1/-1 on PRs. Maybe we can build something in gerrit style for automate the process using the github API for merging directly on 2x+1 of maintainers. Yours RenĂ© ---
**Author:** ![Greg\_DeKoenigsberg1](https://avatars.discourse-cdn.com/v4/letter/g/838e76/32.png) [@Greg\_DeKoenigsberg1](https://forum.ansible.com/u/Greg_DeKoenigsberg1)\ **Post date:** [April 27, 2015, 1:55pm UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/13 "2015-04-27T13:55:46Z")
> Hi Greg > > I really love the idea and your proposal! It is basically what I ask for few > months ago. So I definitely would like to try this out on extras! Fortunately, I need to make no claim about being original. 🙂 > Maybe technically a few thoughts: > > Along with the "author" field in the modules, I thought about adding a > "maintainers" list to the modules (with the github account names and/or > email addresses), starting with the 3rd party committers of the modules, > giving them opt-out. > > So any maintainer gets an email on issues, PRs and commits related to that > module and can give +1/-1 on PRs. Maybe we can build something in gerrit > style for automate the process using the github API for merging directly on > 2x+1 of maintainers. So if I understand, we basically we update this file: [https://github.com/ansible/ansible/blob/devel/examples/DOCUMENTATION.yml](https://github.com/ansible/ansible/blob/devel/examples/DOCUMENTATION.yml) ...and add "maintainers" as a recommended field? --g ---
**Author:** ![Rene\_Moser](https://avatars.discourse-cdn.com/v4/letter/r/7bcc69/32.png) [@Rene\_Moser](https://forum.ansible.com/u/Rene_Moser)\ **Post date:** [April 30, 2015, 9:37am UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/14 "2015-04-30T09:37:31Z")
Yes, this would be the first step, I am unsure what format would make sense, e.g. maintainers: - { name: René Moser, email: [rene@example.com](mailto:rene@example.com), github: resmo } - { name: John Doe, email: [john@example.com](mailto:john@example.com), github: john } This way, maintainers can chose to be notified by github (using comments and @resmo) or by email. 1. Step: After that anyone has to make a tool, which notifies the maintainers if the PR or issue is _not_ from the maintainers. If a PR is from a maintainer, then merge the PR immediately after successful travis build. Such kind of a workflow would be awesome. Yours René ---
**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\ **Post date:** [April 30, 2015, 9:40am UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/15 "2015-04-30T09:40:05Z")
​How about an ansibot for irc users in #ansible-devel (and add an optional freenode irc​ nick to the maintainers)? ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [April 30, 2015, 11:32am UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/16 "2015-04-30T11:32:54Z")
I believe that I am a big -1 on adding maintainers to the source of a module for this purpose. This could easily get out of date, and bloated with information. And making a code change to add a new maintainer doesn’t sound reasonable. I’d propose another external tool which would allow individuals to pick their subscriptions. And actually I just started expanding my previous project to try and support this. ---
**Author:** ![Rob\_White](https://avatars.discourse-cdn.com/v4/letter/r/71c47a/32.png) [@Rob\_White](https://forum.ansible.com/u/Rob_White)\ **Post date:** [May 7, 2015, 2:53am UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/17 "2015-05-07T02:53:48Z")
So, how do you go about building a community team? And how to ensure the community team is on the same page as the Ansible team when it comes to how a module should work and if it should exist in the first place? I'd be happy to participate, but then I'm sure that most people with an open PR will say the same 😉 ---
**Author:** ![Doug\_Luce](https://avatars.discourse-cdn.com/v4/letter/d/cc9497/32.png) [@Doug\_Luce](https://forum.ansible.com/u/Doug_Luce)\ **Post date:** [May 7, 2015, 3:12am UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/18 "2015-05-07T03:12:21Z")
Thanks for submitting your pull request! We thrive on the contributions from people like you. Before we take a look at your pull request, we ask that you first review two outstanding pull requests that have the blue "review" label. You can find them easily by going to this url: ... Our PR review guide is at .... Once you have reviewed two pull requests, we will mark your submission with a review label and put it on the fast track to merge. We know it's a little extra work, but your effort will help to make sure we keep a quality system for everyone. It'll also get what you need folded in quicker! ---
**Author:** ![Jonathan\_Mainguy](https://avatars.discourse-cdn.com/v4/letter/j/e274bd/32.png) [@Jonathan\_Mainguy](https://forum.ansible.com/u/Jonathan_Mainguy)\ **Post date:** [May 7, 2015, 3:23am UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/19 "2015-05-07T03:23:06Z")
There should be no strings attached with submitting a PR. Everyone is welcome to submit PRs. Bug reports, and test others. Do it if you want, don’t if you don’t. Its literally that easy. ---
**Author:** ![Doug\_Luce](https://avatars.discourse-cdn.com/v4/letter/d/cc9497/32.png) [@Doug\_Luce](https://forum.ansible.com/u/Doug_Luce)\ **Post date:** [May 7, 2015, 3:26am UTC](https://forum.ansible.com/t/extras-triage-proposal/18041/20 "2015-05-07T03:26:29Z")
What about the string that keeps your PR from ever getting merged in because there's 203984293 outstanding pull requests and a non-infinite number of Ansible devs? [Next page](https://forum.ansible.com/t/extras-triage-proposal/18041.md?page=2)