[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Pulp-dev] Plugin triage



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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]