Re: [Pulp-dev] Plugin triage

[Daniel Alley]

I'll make a second proposal.

Each plugin could have their own IRC channel (several already do).  We
could invite pulpbot to each channel and make whatever (hopefully minor?)
modifications are necessary to restrict triages in those channels to their
associated plugin and also store the logs under different names.

Then QE can still have visibility into the process, which they don't have
with more ad-hoc processes.

On Wed, Mar 7, 2018 at 9:49 AM, Preethi Thomas  wrote:

>
>
> On Wed, Mar 7, 2018 at 8:58 AM, Robin Chan  wrote:
>
>> I would like to hear from QE since I know they had some concerns here.
>> Since the Pulp QE team is much smaller, having to manage attendance to
>> multiple traige's per week is more of a strain on them to have the
>> interruptions and their expertise may not be as clearly delineated as a
>> larger team which has had some time to align with plugin teams. I hope they
>> can chime in on their specific concerns here and suggestions on what needs
>> they have or suggestions.
>>
>
> This is definitely a concern. Being able to watch triage and having the
> triage log available does benefit us in adding issues to the automation
> backlog and and in priorotizing them. And their may be specific issues that
> QE has filed that would be of particular interest to them. So keeping track
> of which triages to attend and the possibility of having overlapping
> triages is concerning.
>
>
>>
>> +1 to Daniel's suggestion on perhaps ordering the items sounds promising.
>> If we wanted to make a small tweak, maybe we can have the core (and is
>> packaging meaning build packaging and not a plug in) could go first and try
>> to order 1-2 plugins (maybe the more active ones that we are triaging more
>> issues on that others), and then letting the rest go in whatever order
>> would allow us to evaluate and try out the predictions/concerns Daniel
>> listed.
>> I think some of the issue is that some of the items are not always tagged
>> appropriately? I think if plugin teams could at least ensure those are
>> tagged appropriately that might cut down on some of the discussion on
>> those? Or perhaps we can set a rule that if 2 members of plugin team aren't
>> present, the item is automatically skipped?
>>
>
> +1 to this suggestion. I think this will keep the triage in a somewhat
> orderly manner. And allows everyone to participate
>
>>
>> Some of my concerns regarding individual plugin triages:
>> Ina brings up a point that if triage continues to maintain the power to
>> add things to the current sprint, then lack of whole team feedback could be
>> problematic. I think we may not want to grant that power until we are
>> handling plugin staffing truly independently, which I don't believe we are
>> able to do yet.
>> If plugin items are triaged separately, will they still have the pulpbot
>> minutes recorded? Or would that be a downside to doing them independently?
>>
>
> +1 on this as well.
>
>>
>>
>> Robin
>>
>> On Tue, Mar 6, 2018 at 12:30 PM, Ina Panova  wrote:
>>
>>> 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  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 

Re: [Pulp-dev] Plugin triage

[Preethi Thomas]

On Wed, Mar 7, 2018 at 8:58 AM, Robin Chan  wrote:

> I would like to hear from QE since I know they had some concerns here.
> Since the Pulp QE team is much smaller, having to manage attendance to
> multiple traige's per week is more of a strain on them to have the
> interruptions and their expertise may not be as clearly delineated as a
> larger team which has had some time to align with plugin teams. I hope they
> can chime in on their specific concerns here and suggestions on what needs
> they have or suggestions.
>

This is definitely a concern. Being able to watch triage and having the
triage log available does benefit us in adding issues to the automation
backlog and and in priorotizing them. And their may be specific issues that
QE has filed that would be of particular interest to them. So keeping track
of which triages to attend and the possibility of having overlapping
triages is concerning.


>
> +1 to Daniel's suggestion on perhaps ordering the items sounds promising.
> If we wanted to make a small tweak, maybe we can have the core (and is
> packaging meaning build packaging and not a plug in) could go first and try
> to order 1-2 plugins (maybe the more active ones that we are triaging more
> issues on that others), and then letting the rest go in whatever order
> would allow us to evaluate and try out the predictions/concerns Daniel
> listed.
> I think some of the issue is that some of the items are not always tagged
> appropriately? I think if plugin teams could at least ensure those are
> tagged appropriately that might cut down on some of the discussion on
> those? Or perhaps we can set a rule that if 2 members of plugin team aren't
> present, the item is automatically skipped?
>

+1 to this suggestion. I think this will keep the triage in a somewhat
orderly manner. And allows everyone to participate

>
> Some of my concerns regarding individual plugin triages:
> Ina brings up a point that if triage continues to maintain the power to
> add things to the current sprint, then lack of whole team feedback could be
> problematic. I think we may not want to grant that power until we are
> handling plugin staffing truly independently, which I don't believe we are
> able to do yet.
> If plugin items are triaged separately, will they still have the pulpbot
> minutes recorded? Or would that be a downside to doing them independently?
>

+1 on this as well.

>
>
> Robin
>
> On Tue, Mar 6, 2018 at 12:30 PM, Ina Panova  wrote:
>
>> 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  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 
>>> 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 

Re: [Pulp-dev] Plugin triage

[Robin Chan]

I would like to hear from QE since I know they had some concerns here.
Since the Pulp QE team is much smaller, having to manage attendance to
multiple traige's per week is more of a strain on them to have the
interruptions and their expertise may not be as clearly delineated as a
larger team which has had some time to align with plugin teams. I hope they
can chime in on their specific concerns here and suggestions on what needs
they have or suggestions.

+1 to Daniel's suggestion on perhaps ordering the items sounds promising.
If we wanted to make a small tweak, maybe we can have the core (and is
packaging meaning build packaging and not a plug in) could go first and try
to order 1-2 plugins (maybe the more active ones that we are triaging more
issues on that others), and then letting the rest go in whatever order
would allow us to evaluate and try out the predictions/concerns Daniel
listed.
I think some of the issue is that some of the items are not always tagged
appropriately? I think if plugin teams could at least ensure those are
tagged appropriately that might cut down on some of the discussion on
those? Or perhaps we can set a rule that if 2 members of plugin team aren't
present, the item is automatically skipped?

Some of my concerns regarding individual plugin triages:
Ina brings up a point that if triage continues to maintain the power to add
things to the current sprint, then lack of whole team feedback could be
problematic. I think we may not want to grant that power until we are
handling plugin staffing truly independently, which I don't believe we are
able to do yet.
If plugin items are triaged separately, will they still have the pulpbot
minutes recorded? Or would that be a downside to doing them independently?

Robin

On Tue, Mar 6, 2018 at 12:30 PM, Ina Panova  wrote:

> 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  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 
>> 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 

Re: [Pulp-dev] Plugin triage

[Ina Panova]

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

Re: [Pulp-dev] Plugin triage

[Brian Bouterse]

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