[Pulp-dev] Plugin triage

Brian Bouterse bbouters at redhat.com
Mon Mar 5 23:05:36 UTC 2018


Currently the biweekly triage query includes a large number of unrelated
topics: Pulp, RPM, Puppet, Python, Ansible (the pulp3 role plugin),
Packaging, OS Tree, Crane, Docker, External, and File Support. These are
all different top-level pulp.plan.io projects in Redmine. These are so many
specializations I think it makes sense to have issues triaged by just the
people who focus on them. Also once per week may or may not be the right
frequency for all of these things which could bring people into meetings
they may not contribute to or benefit from. +1 to having plugin teams
triage issues how they want.

For Ansible for example, @daviddavis and I can just talk about issues as
they come it. I have it set to email me when they are filed, so we don't
need a meeting at all.

What about a gradual transition? If/when plugin/project committers decide
to do it differently, then can email pulp-dev asking to be removed and
someone can update the query.

What do you think?


On Tue, Feb 27, 2018 at 11:47 AM, David Davis <daviddavis at redhat.com> wrote:

> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180305/bdae9691/attachment.htm>


More information about the Pulp-dev mailing list