It makes sense to let to mini-teams to triage the issues, but the decision whether to put or not on the sprint still should be addressed by whole team, or at least acknowledged.
-------- Regards, Ina Panova Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where there is no path and leave a trail." On Tue, Mar 6, 2018 at 3:29 AM, Daniel Alley <dal...@redhat.com> wrote: > I'm fine with this. I dislike the idea of multiple meetings but I think > that what will end up happening is that the issue load for each project > individually will be low enough that they will can and will all end up > being handled asynchronously as they come in. I also think that letting > each plugin decide what is best for them. > > But just to throw this out there, there are a few other things we could do > to help address the problem. > > We could modify the triage bot to group the issues by type instead of > listing them chronologically by number. All core issues would be handled > first, followed by the plugin with the largest number of issues, followed > by the plugin with the next largest, etc. The triage bot could know the > composition of the plugin teams and ping the relevant members when a group > of issues that concerns them comes up. > > Pros: > > - No concerns about lack of cross-pollination, everything is still > completely transparent > - Community members could still be involved and/or observe the > process, which they can't do if every plugin meeting is separate and done > in email or IRC > > Cons: > > - If you're involved in triaging issues a couple minutes apart, what can > you _really_ do in that time? > - Multiple interruptions, not *necessarily* gaining much efficiency > - Triage lead still would still have to be involved the entire time, > whereas ideally someone directly involved with that plugin would be in > control > - Triage would still take a long time, and would hold up #pulp-dev for > that duration > > > On Mon, Mar 5, 2018 at 6:05 PM, Brian Bouterse <bbout...@redhat.com> > wrote: > >> Currently the biweekly triage query includes a large number of unrelated >> topics: Pulp, RPM, Puppet, Python, Ansible (the pulp3 role plugin), >> Packaging, OS Tree, Crane, Docker, External, and File Support. These are >> all different top-level pulp.plan.io projects in Redmine. These are so >> many specializations I think it makes sense to have issues triaged by just >> the people who focus on them. Also once per week may or may not be the >> right frequency for all of these things which could bring people into >> meetings they may not contribute to or benefit from. +1 to having plugin >> teams triage issues how they want. >> >> For Ansible for example, @daviddavis and I can just talk about issues as >> they come it. I have it set to email me when they are filed, so we don't >> need a meeting at all. >> >> What about a gradual transition? If/when plugin/project committers decide >> to do it differently, then can email pulp-dev asking to be removed and >> someone can update the query. >> >> What do you think? >> >> >> On Tue, Feb 27, 2018 at 11:47 AM, David Davis <davidda...@redhat.com> >> wrote: >> >>> At our last retrospective, we discussed the possibility of not triaging >>> plugin issues as part of our biweekly triage sessions. We didn’t reach an >>> agreement so I took the action item to start a discussion on pulp-dev. >>> >>> First off some benefits of not triaging plugin issues as part of our >>> triage sessions: >>> >>> - If we let plugin teams triage their own issues, they can select a time >>> when the whole team is able to meet. Our biweekly meeting tends to only >>> involve a subsets of plugin teams. >>> - Time is wasted when plugin issues come up and usually just the plugin >>> team members discuss it. >>> - We don’t have a consistent policy around which plugin issues we >>> triage. For instance, we don’t triage pulp_deb. >>> >>> There are some downsides however: >>> >>> - I think the biggest issue is that there’ll be less transparency into >>> plugins. This could lead to more siloing and less cross-pollination. >>> - Potentially more meetings if all plugins decide to schedule their own >>> triage meetings. >>> - Plugin issues could go untriaged if plugin teams aren’t responsible. >>> >>> A couple solutions to the problem that were proposed: >>> >>> - Ask plugin teams schedule their own triage meetings. They could >>> probably do this on a less regular basis. >>> - Have plugin teams triage their issues how they want. This could even >>> be asynchronously as issues come in. Could be done via IRC/email/etc. >>> >>> I think at the least it might be worth trying out an alternative >>> approach for a limited time (e.g. 2 months) and then reevaluating. Thoughts? >>> >>> David >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulpemail@example.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulpfirstname.lastname@example.org >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > Pulpemail@example.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulpfirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/pulp-dev