[Pulp-dev] Plugin triage

Tue Mar 6 17:30:51 UTC 2018

It makes sense to let to mini-teams to triage the issues, but the decision
whether to put or not on the sprint still should be addressed by whole
team, or at least acknowledged.

--------
Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

On Tue, Mar 6, 2018 at 3:29 AM, Daniel Alley <dalley at redhat.com> wrote:

> I'm fine with this.  I dislike the idea of multiple meetings but I think
> that what will end up happening is that the issue load for each project
> individually will be low enough that they will can and will all end up
> being handled asynchronously as they come in.  I also think that letting
> each plugin decide what is best for them.
>
> But just to throw this out there, there are a few other things we could do
> to help address the problem.
>
> We could modify the triage bot to group the issues by type instead of
> listing them chronologically by number.  All core issues would be handled
> first, followed by the plugin with the largest number of issues, followed
> by the plugin with the next largest, etc.  The triage bot could know the
> composition of the plugin teams and ping the relevant members when a group
> of issues that concerns them comes up.
>
> Pros:
>
> - No concerns about lack of cross-pollination, everything is still
> completely transparent
>     - Community members could still be involved and/or observe the
> process, which they can't do if every plugin meeting is separate and done
> in email or IRC
>
> Cons:
>
> - If you're involved in triaging issues a couple minutes apart, what can
> you _really_ do in that time?
>     - Multiple interruptions, not *necessarily* gaining much efficiency
>     - Triage lead still would still have to be involved the entire time,
> whereas ideally someone directly involved with that plugin would be in
> control
> - Triage would still take a long time, and would hold up #pulp-dev for
> that duration
>
>
> On Mon, Mar 5, 2018 at 6:05 PM, Brian Bouterse <bbouters at redhat.com>
> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> _______________________________________________
> 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/20180306/3ef5dd5f/attachment.htm>