[Pulp-dev] Plugin triage

[David Davis]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180227/9a3c9080/attachment.htm>