<div dir="ltr">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.<div><br></div><div>First off some benefits of not triaging plugin issues as part of our triage sessions:</div><div><br></div><div>- 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. </div><div>- Time is wasted when plugin issues come up and usually just the plugin team members discuss it. </div><div>- We don’t have a consistent policy around which plugin issues we triage. For instance, we don’t triage pulp_deb.</div><div><br></div><div>There are some downsides however:</div><div><br></div><div>- I think the biggest issue is that there’ll be less transparency into plugins. This could lead to more siloing and less cross-pollination.</div><div>- Potentially more meetings if all plugins decide to schedule their own triage meetings.</div><div>- Plugin issues could go untriaged if plugin teams aren’t responsible.</div><div><br></div><div>A couple solutions to the problem that were proposed:</div><div><br></div><div>- Ask plugin teams schedule their own triage meetings. They could probably do this on a less regular basis.</div><div>- 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.</div><div><br></div><div>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?</div><div><div><div class="m_-1001007881786136385gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
</div></div>