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 Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
