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?