Bug Triage "Team"

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Bug Triage "Team"

slide
There was a discussion in the Governance Meeting yesterday [1] about creating a Bug Triage "Team." The goal of this team would be to triage issues on [2] to make sure that they are assigned to the correct component, assigned to the correct developer and are actually still valid. The reason the idea of an official "Team" was put forward would be so that those people would have the ok to touch issues across the board. There are some people that do this already (Daniel Beck and a few others) who most people know, so they have some credibility already, some of the volunteers for this may not, so we thought being part of the team would allow users have more credibility if they are less well known to the community.

We discussed in the meeting that we should focus on a couple of key areas

1) issues assigned to the core component with no assignee
2) issues assigned to plugins that are part of the "recommended" set of plugins for the new install wizard
3) issues that are not assigned to anything or anyone in particular

The outcome of a triage on a specific issue would be that the correct component(s) and assignee were there. In addition, if possible a test to see how reproducible the issue is. If an issue has languished for some time and is using very old versions of Jenkins/plugin/etc, we would close the issue (it could still be reopened if someone is still seeing the issue).

I'd like to get some feedback on this proposal: 

1) Do we have the correct scope planned out?
2) Is more detail needed?
3) Anything else you want to ask/propose?

If you want to participate in the team, please let me know and I'll start collecting a list of people. Please note, you don't need to be a developer to help here, if you can create a Jenkins instance and try and reproduce issues, that is great too, or even just getting the component(s) and assignees in place would be very helpful.

Thanks,

Alex Earl



--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfuKH8SyZdg_MPDi963hLy-HAAjfWS8HSYw3zdHLk7FNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Owen Mehegan-2

This sounds like a solid first pass to me, worth trying out for a month or so to see how it goes.

I'm also interested in helping, so put me on the list!

On Jan 19, 2017 9:34 AM, "Slide" <[hidden email]> wrote:
There was a discussion in the Governance Meeting yesterday [1] about creating a Bug Triage "Team." The goal of this team would be to triage issues on [2] to make sure that they are assigned to the correct component, assigned to the correct developer and are actually still valid. The reason the idea of an official "Team" was put forward would be so that those people would have the ok to touch issues across the board. There are some people that do this already (Daniel Beck and a few others) who most people know, so they have some credibility already, some of the volunteers for this may not, so we thought being part of the team would allow users have more credibility if they are less well known to the community.

We discussed in the meeting that we should focus on a couple of key areas

1) issues assigned to the core component with no assignee
2) issues assigned to plugins that are part of the "recommended" set of plugins for the new install wizard
3) issues that are not assigned to anything or anyone in particular

The outcome of a triage on a specific issue would be that the correct component(s) and assignee were there. In addition, if possible a test to see how reproducible the issue is. If an issue has languished for some time and is using very old versions of Jenkins/plugin/etc, we would close the issue (it could still be reopened if someone is still seeing the issue).

I'd like to get some feedback on this proposal: 

1) Do we have the correct scope planned out?
2) Is more detail needed?
3) Anything else you want to ask/propose?

If you want to participate in the team, please let me know and I'll start collecting a list of people. Please note, you don't need to be a developer to help here, if you can create a Jenkins instance and try and reproduce issues, that is great too, or even just getting the component(s) and assignees in place would be very helpful.

Thanks,

Alex Earl



--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfuKH8SyZdg_MPDi963hLy-HAAjfWS8HSYw3zdHLk7FNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAHtcACFfDqbu7xPEjVK3wyGEJAut3wwg8c7Mwe8%2Bk85Cwz10Mw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Jesse Glick-4
In reply to this post by slide
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:
> The outcome of a triage on a specific issue would be that the correct
> component(s) and assignee were there.

Do we really need to set an assignee? For example for most
`{workflow,pipeline}-*-plugin` components there is intentionally no
default assignee. If and when someone intends to work on a fix, they
can assign to themselves.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Mark Waite-2


On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:
> The outcome of a triage on a specific issue would be that the correct
> component(s) and assignee were there.

Do we really need to set an assignee? For example for most
`{workflow,pipeline}-*-plugin` components there is intentionally no
default assignee. If and when someone intends to work on a fix, they
can assign to themselves.


As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite

 
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

slide
If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:
> The outcome of a triage on a specific issue would be that the correct
> component(s) and assignee were there.

Do we really need to set an assignee? For example for most
`{workflow,pipeline}-*-plugin` components there is intentionally no
default assignee. If and when someone intends to work on a fix, they
can assign to themselves.


As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Mark Waite-2


On Thu, Jan 19, 2017 at 12:51 PM Slide <[hidden email]> wrote:
If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 


Confirming that bugs are repeatable is very valuable.  I feel like I've wasted time on many occasions trying to verify poorly phrased bug reports.  Recently I've become more direct (harsh) and less willing to spend time trying to duplicate a poorly phrased bug report.

Cem Kaner's online course "Bug Advocacy" is a great introduction to effective bug reporting...

Mark Waite
 
On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:
> The outcome of a triage on a specific issue would be that the correct
> component(s) and assignee were there.

Do we really need to set an assignee? For example for most
`{workflow,pipeline}-*-plugin` components there is intentionally no
default assignee. If and when someone intends to work on a fix, they
can assign to themselves.


As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFXoCOozn%2B2bBce03X5DZbyNPA%3DucnAEjrKkzcpRSx4pQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Baptiste MATHUS

2017-01-19 21:31 GMT+01:00 Mark Waite <[hidden email]>:


On Thu, Jan 19, 2017 at 12:51 PM Slide <[hidden email]> wrote:
If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 


Confirming that bugs are repeatable is very valuable.  I feel like I've wasted time on many occasions trying to verify poorly phrased bug reports.  Recently I've become more direct (harsh) and less willing to spend time trying to duplicate a poorly phrased bug report.

We could totally add something in our docs about that. Something like "If you expect maintainers to spend hours, or even days, on their free time on your case, then we recommend you spend more than 30 seconds filing your reports. Or your hopes will most probably fade out quickly." 😛
 

Cem Kaner's online course "Bug Advocacy" is a great introduction to effective bug reporting...

Mark Waite
 
On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:
> The outcome of a triage on a specific issue would be that the correct
> component(s) and assignee were there.

Do we really need to set an assignee? For example for most
`{workflow,pipeline}-*-plugin` components there is intentionally no
default assignee. If and when someone intends to work on a fix, they
can assign to themselves.


As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFXoCOozn%2B2bBce03X5DZbyNPA%3DucnAEjrKkzcpRSx4pQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7OvtVqiegiPA5bGuZbSg4MXLspc5TrksN_TMZL_PzJOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Ulli Hafner
In reply to this post by slide
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:
> The outcome of a triage on a specific issue would be that the correct
> component(s) and assignee were there.

Do we really need to set an assignee? For example for most
`{workflow,pipeline}-*-plugin` components there is intentionally no
default assignee. If and when someone intends to work on a fix, they
can assign to themselves.


As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Mark Waite-2


On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[hidden email]> wrote:
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


In my case, I'm one maintainer with 400+ bugs assigned across the two plugins I maintain.  If someone assigns all the bugs for the git plugin and the git client plugin to me, "assignee" will no longer be a useful field to me and I will ignore it.  I already ignore severity and several other fields, so that isn't a big problem.  I'd then maintain a record of my "working set" somewhere else.  It will probably be less visible to others, since I won't necessarily try to use Jira to maintain it.  I'm fine with maintaining my "working set" elsewhere, I only use Jira for the working set because I'm already there reading bug reports.

I acknowledge that I'm an exception (since the git plugin and the git client plugin are second only to the Subversion plugin in the total count of bugs open against them), but since Jesse noted that others use the same assignment process which I use, I may not be as much of an exception as you think.

Thanks!
Mark Waite
 
Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:
> The outcome of a triage on a specific issue would be that the correct
> component(s) and assignee were there.

Do we really need to set an assignee? For example for most
`{workflow,pipeline}-*-plugin` components there is intentionally no
default assignee. If and when someone intends to work on a fix, they
can assign to themselves.


As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

stephenconnolly
I also would love if we cleared out the assignee setting entirely.

There are loads of plugins were somebody else has taken up (great) but I still get assigned the issue.

I'd rather use assignee to track actually picking up the issue. Status to track triage state.

Esp in credentials (which I have been repeatedly and actively scrubbing) use of assignee also helps identify when somebody starts working on the issue.

Ideally the status would have a state to indicate that the JIRA has been accepted as a bug.

Another status to indicate that it is ready to be worked on would be awesome

We just need to clarify for everyone what those statuses mean (if they are not self evident)
On Fri 20 Jan 2017 at 00:21, Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[hidden email]> wrote:
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


In my case, I'm one maintainer with 400+ bugs assigned across the two plugins I maintain.  If someone assigns all the bugs for the git plugin and the git client plugin to me, "assignee" will no longer be a useful field to me and I will ignore it.  I already ignore severity and several other fields, so that isn't a big problem.  I'd then maintain a record of my "working set" somewhere else.  It will probably be less visible to others, since I won't necessarily try to use Jira to maintain it.  I'm fine with maintaining my "working set" elsewhere, I only use Jira for the working set because I'm already there reading bug reports.

I acknowledge that I'm an exception (since the git plugin and the git client plugin are second only to the Subversion plugin in the total count of bugs open against them), but since Jesse noted that others use the same assignment process which I use, I may not be as much of an exception as you think.

Thanks!
Mark Waite
 
Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:


> The outcome of a triage on a specific issue would be that the correct


> component(s) and assignee were there.





Do we really need to set an assignee? For example for most


`{workflow,pipeline}-*-plugin` components there is intentionally no


default assignee. If and when someone intends to work on a fix, they


can assign to themselves.




As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 


--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.











--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.


For more options, visit https://groups.google.com/d/optout.










--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.


--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwGf466pLG_mnRQ8e0jYGB%2B%3DX-pOKpwfo32dDixnUbhSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Ulli Hafner
In reply to this post by Mark Waite-2

Am 20.01.2017 um 01:21 schrieb Mark Waite <[hidden email]>:



On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[hidden email]> wrote:
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


In my case, I'm one maintainer with 400+ bugs assigned across the two plugins I maintain.  If someone assigns all the bugs for the git plugin and the git client plugin to me, "assignee" will no longer be a useful field to me and I will ignore it.  I already ignore severity and several other fields, so that isn't a big problem.  I'd then maintain a record of my "working set" somewhere else.  It will probably be less visible to others, since I won't necessarily try to use Jira to maintain it.  I'm fine with maintaining my "working set" elsewhere, I only use Jira for the working set because I'm already there reading bug reports.


I see, if these issues are all only mapped to your component then this should work. I have several issues that have as component one of my plugins and another plugin (or core). Here the assignee identifies who is responsible for the bug and who needs to find a fix. If there would be no assignee this means that nobody actually is doing anything. 

Can’t you use the in progress status for your working set?  

I acknowledge that I'm an exception (since the git plugin and the git client plugin are second only to the Subversion plugin in the total count of bugs open against them), but since Jesse noted that others use the same assignment process which I use, I may not be as much of an exception as you think.

Actually I’m not sure how many different processes we have for issues. This depends on the plugin authors, and we have many of them ;-)

However, it would make sense if we use the tool in the same way. Otherwise users who report bugs are confused about the state of these bugs. 


Thanks!
Mark Waite
 
Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:
> The outcome of a triage on a specific issue would be that the correct
> component(s) and assignee were there.

Do we really need to set an assignee? For example for most
`{workflow,pipeline}-*-plugin` components there is intentionally no
default assignee. If and when someone intends to work on a fix, they
can assign to themselves.


As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/24E5796E-EB38-45D5-B9F3-580078345485%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Ulli Hafner
In reply to this post by stephenconnolly

Am 20.01.2017 um 08:16 schrieb Stephen Connolly <[hidden email]>:

I also would love if we cleared out the assignee setting entirely.

How do we identify who is responsible for the issue (or who is the owner)? If there is no assignee then nobody gets notified about new bug reports or issue updates (if you are not watching an issue).


There are loads of plugins were somebody else has taken up (great) but I still get assigned the issue.


Then we should set the default assignee accordingly.

I'd rather use assignee to track actually picking up the issue. Status to track triage state.

Esp in credentials (which I have been repeatedly and actively scrubbing) use of assignee also helps identify when somebody starts working on the issue.

There is a status in progress which we have activated in Jira for such a use case.


Ideally the status would have a state to indicate that the JIRA has been accepted as a bug.

This makes sense. Currently we have no idea if a developer has accepted a bug report as valid. Since no assignee is attached to most of the new issues the reporter has no clue to see if the bug has been recognized or not. 

We are using in several other projects an additional initial Jira status ’New’. This status indicates that the bug has been created, but it has not yet been confirmed by the developer team that it is valid. From ‚New‘ there is a transition to ‚Open‘: this transition can be used by our new triage team to indicate that the issue has been reviewed and accepted as a bug. This transition should only be started if the issue is reproducible and if all information are provided. The triage team then could have a filter on all ’New’ issues to see what needs to be reviewed.  
 

Another status to indicate that it is ready to be worked on would be awesome

'In Progress' is already available: https://confluence.atlassian.com/adminjiraserver071/working-with-workflows-802592661.html


We just need to clarify for everyone what those statuses mean (if they are not self evident)
On Fri 20 Jan 2017 at 00:21, Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[hidden email]> wrote:
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


In my case, I'm one maintainer with 400+ bugs assigned across the two plugins I maintain.  If someone assigns all the bugs for the git plugin and the git client plugin to me, "assignee" will no longer be a useful field to me and I will ignore it.  I already ignore severity and several other fields, so that isn't a big problem.  I'd then maintain a record of my "working set" somewhere else.  It will probably be less visible to others, since I won't necessarily try to use Jira to maintain it.  I'm fine with maintaining my "working set" elsewhere, I only use Jira for the working set because I'm already there reading bug reports.

I acknowledge that I'm an exception (since the git plugin and the git client plugin are second only to the Subversion plugin in the total count of bugs open against them), but since Jesse noted that others use the same assignment process which I use, I may not be as much of an exception as you think.

Thanks!
Mark Waite
 
Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:


> The outcome of a triage on a specific issue would be that the correct


> component(s) and assignee were there.





Do we really need to set an assignee? For example for most


`{workflow,pipeline}-*-plugin` components there is intentionally no


default assignee. If and when someone intends to work on a fix, they


can assign to themselves.




As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 


--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.












--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.


For more options, visit https://groups.google.com/d/optout.











--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.


--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwGf466pLG_mnRQ8e0jYGB%2B%3DX-pOKpwfo32dDixnUbhSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

stephenconnolly
On 20 January 2017 at 10:29, Ullrich Hafner <[hidden email]> wrote:

Am 20.01.2017 um 08:16 schrieb Stephen Connolly <[hidden email]>:

I also would love if we cleared out the assignee setting entirely.

How do we identify who is responsible for the issue (or who is the owner)? If there is no assignee then nobody gets notified about new bug reports or issue updates (if you are not watching an issue).

How do we identify that the issue is available for somebody to pick up and work on?

It is ok to use the assignee if you are a plugin maintainer that wants complete control and does not seek to have others grow into helping maintain your plugin.

I have too many plugins to want to be the sole person responsible for fixing issues. (There are some plugins where I need to control what goes in, but that doesn't mean I want to develop every fix myself)

I prefer to leave issues unassigned until there is somebody working on them.

Plugin maintainers should be scrubbing NEW and INCOMPLETE issues and transitioning them into OPEN, back to INCOMPLETE or over to REJECTED.

Then anyone can pick up an unassigned issue in the OPEN state (or better yet have a TODO state to indicate that the maintainer is looking for implementation)



There are loads of plugins were somebody else has taken up (great) but I still get assigned the issue.


Then we should set the default assignee accordingly.

I'd rather use assignee to track actually picking up the issue. Status to track triage state.

Esp in credentials (which I have been repeatedly and actively scrubbing) use of assignee also helps identify when somebody starts working on the issue.

There is a status in progress which we have activated in Jira for such a use case.


Ideally the status would have a state to indicate that the JIRA has been accepted as a bug.

This makes sense. Currently we have no idea if a developer has accepted a bug report as valid. Since no assignee is attached to most of the new issues the reporter has no clue to see if the bug has been recognized or not. 

We are using in several other projects an additional initial Jira status ’New’. This status indicates that the bug has been created, but it has not yet been confirmed by the developer team that it is valid. From ‚New‘ there is a transition to ‚Open‘: this transition can be used by our new triage team to indicate that the issue has been reviewed and accepted as a bug. This transition should only be started if the issue is reproducible and if all information are provided. The triage team then could have a filter on all ’New’ issues to see what needs to be reviewed.  
 

Another status to indicate that it is ready to be worked on would be awesome

'In Progress' is already available: https://confluence.atlassian.com/adminjiraserver071/working-with-workflows-802592661.html


We just need to clarify for everyone what those statuses mean (if they are not self evident)
On Fri 20 Jan 2017 at 00:21, Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[hidden email]> wrote:
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


In my case, I'm one maintainer with 400+ bugs assigned across the two plugins I maintain.  If someone assigns all the bugs for the git plugin and the git client plugin to me, "assignee" will no longer be a useful field to me and I will ignore it.  I already ignore severity and several other fields, so that isn't a big problem.  I'd then maintain a record of my "working set" somewhere else.  It will probably be less visible to others, since I won't necessarily try to use Jira to maintain it.  I'm fine with maintaining my "working set" elsewhere, I only use Jira for the working set because I'm already there reading bug reports.

I acknowledge that I'm an exception (since the git plugin and the git client plugin are second only to the Subversion plugin in the total count of bugs open against them), but since Jesse noted that others use the same assignment process which I use, I may not be as much of an exception as you think.

Thanks!
Mark Waite
 
Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:


> The outcome of a triage on a specific issue would be that the correct


> component(s) and assignee were there.





Do we really need to set an assignee? For example for most


`{workflow,pipeline}-*-plugin` components there is intentionally no


default assignee. If and when someone intends to work on a fix, they


can assign to themselves.




As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 


--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.












--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.


For more options, visit https://groups.google.com/d/optout.











--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.


--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwGf466pLG_mnRQ8e0jYGB%2B%3DX-pOKpwfo32dDixnUbhSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzzBZPUeQcFkNG_%3DnB2%3DYR-i1G4LMiEU82zefD_g8MLcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

stephenconnolly
Something like:

NEW -> OPEN or TODO or INCOMPLETE
INCOMPLETE -> NEW (when the creator added more details)
OPEN -> TODO or RESOLVED
TODO -> IN PROGRESS (or OPEN or RESOLVED)
IN PROGRESS -> TODO or IN REVIEW or RESOLVED
RESOLVED -> VERIFY or IN PROGRESS
REOPENED -> TODO or RESOLVED
VERIFY -> REOPENED or CLOSED

The idea being that the person opening the ticket gets their "response" to the resolution when it's in the VERIFY state. The only states that a person opening a ticket can push it to are INCOMPLETE->NEW , VERIFY->REOPENED or CLOSED (plus perhaps some ability to flag as user error and it's not a bug any more).

On 20 January 2017 at 11:03, Stephen Connolly <[hidden email]> wrote:
On 20 January 2017 at 10:29, Ullrich Hafner <[hidden email]> wrote:

Am 20.01.2017 um 08:16 schrieb Stephen Connolly <[hidden email]>:

I also would love if we cleared out the assignee setting entirely.

How do we identify who is responsible for the issue (or who is the owner)? If there is no assignee then nobody gets notified about new bug reports or issue updates (if you are not watching an issue).

How do we identify that the issue is available for somebody to pick up and work on?

It is ok to use the assignee if you are a plugin maintainer that wants complete control and does not seek to have others grow into helping maintain your plugin.

I have too many plugins to want to be the sole person responsible for fixing issues. (There are some plugins where I need to control what goes in, but that doesn't mean I want to develop every fix myself)

I prefer to leave issues unassigned until there is somebody working on them.

Plugin maintainers should be scrubbing NEW and INCOMPLETE issues and transitioning them into OPEN, back to INCOMPLETE or over to REJECTED.

Then anyone can pick up an unassigned issue in the OPEN state (or better yet have a TODO state to indicate that the maintainer is looking for implementation)



There are loads of plugins were somebody else has taken up (great) but I still get assigned the issue.


Then we should set the default assignee accordingly.

I'd rather use assignee to track actually picking up the issue. Status to track triage state.

Esp in credentials (which I have been repeatedly and actively scrubbing) use of assignee also helps identify when somebody starts working on the issue.

There is a status in progress which we have activated in Jira for such a use case.


Ideally the status would have a state to indicate that the JIRA has been accepted as a bug.

This makes sense. Currently we have no idea if a developer has accepted a bug report as valid. Since no assignee is attached to most of the new issues the reporter has no clue to see if the bug has been recognized or not. 

We are using in several other projects an additional initial Jira status ’New’. This status indicates that the bug has been created, but it has not yet been confirmed by the developer team that it is valid. From ‚New‘ there is a transition to ‚Open‘: this transition can be used by our new triage team to indicate that the issue has been reviewed and accepted as a bug. This transition should only be started if the issue is reproducible and if all information are provided. The triage team then could have a filter on all ’New’ issues to see what needs to be reviewed.  
 

Another status to indicate that it is ready to be worked on would be awesome

'In Progress' is already available: https://confluence.atlassian.com/adminjiraserver071/working-with-workflows-802592661.html


We just need to clarify for everyone what those statuses mean (if they are not self evident)
On Fri 20 Jan 2017 at 00:21, Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[hidden email]> wrote:
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


In my case, I'm one maintainer with 400+ bugs assigned across the two plugins I maintain.  If someone assigns all the bugs for the git plugin and the git client plugin to me, "assignee" will no longer be a useful field to me and I will ignore it.  I already ignore severity and several other fields, so that isn't a big problem.  I'd then maintain a record of my "working set" somewhere else.  It will probably be less visible to others, since I won't necessarily try to use Jira to maintain it.  I'm fine with maintaining my "working set" elsewhere, I only use Jira for the working set because I'm already there reading bug reports.

I acknowledge that I'm an exception (since the git plugin and the git client plugin are second only to the Subversion plugin in the total count of bugs open against them), but since Jesse noted that others use the same assignment process which I use, I may not be as much of an exception as you think.

Thanks!
Mark Waite
 
Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:


> The outcome of a triage on a specific issue would be that the correct


> component(s) and assignee were there.





Do we really need to set an assignee? For example for most


`{workflow,pipeline}-*-plugin` components there is intentionally no


default assignee. If and when someone intends to work on a fix, they


can assign to themselves.




As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 


--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.












--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.


For more options, visit https://groups.google.com/d/optout.











--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.


--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwGf466pLG_mnRQ8e0jYGB%2B%3DX-pOKpwfo32dDixnUbhSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzYiz%3DLrD-V%2BTs3MbpsXSqUHhTQet9YvuLvo7yJzjJjxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Arnaud Héritier
In reply to this post by Ulli Hafner


On Fri, Jan 20, 2017 at 11:29 AM, Ullrich Hafner <[hidden email]> wrote:

Am 20.01.2017 um 08:16 schrieb Stephen Connolly <[hidden email]>:

I also would love if we cleared out the assignee setting entirely.

How do we identify who is responsible for the issue (or who is the owner)? If there is no assignee then nobody gets notified about new bug reports or issue updates (if you are not watching an issue).



AFAIR We could change the notifications scheme and automatically notify the component lead (even if we don't assign new issues to him)
But I imagine that it won't satisfy everyone to be spammed by Jira

Otherwise you can create a filter to list issues/components you are interested by and you can add a notification on it
 

There are loads of plugins were somebody else has taken up (great) but I still get assigned the issue.


Then we should set the default assignee accordingly.

This management of default assignments and components lead has to be done manually for now (and thus is rarely done)
Myself I'm against the assignment because it is brake for contributors and users.
It give the feeling that someone will take care of the issue and it's not the case.
An issue should be assigned to someone only if he is planning to working on it to allow contributors to take care of others.
 

I'd rather use assignee to track actually picking up the issue. Status to track triage state.

Esp in credentials (which I have been repeatedly and actively scrubbing) use of assignee also helps identify when somebody starts working on the issue.

There is a status in progress which we have activated in Jira for such a use case.


yes and we may improve the workflow if it is justified ... 


Ideally the status would have a state to indicate that the JIRA has been accepted as a bug.

This makes sense. Currently we have no idea if a developer has accepted a bug report as valid. Since no assignee is attached to most of the new issues the reporter has no clue to see if the bug has been recognized or not. 

We are using in several other projects an additional initial Jira status ’New’. This status indicates that the bug has been created, but it has not yet been confirmed by the developer team that it is valid. From ‚New‘ there is a transition to ‚Open‘: this transition can be used by our new triage team to indicate that the issue has been reviewed and accepted as a bug. This transition should only be started if the issue is reproducible and if all information are provided. The triage team then could have a filter on all ’New’ issues to see what needs to be reviewed.  
 

Another status to indicate that it is ready to be worked on would be awesome

'In Progress' is already available: https://confluence.atlassian.com/adminjiraserver071/working-with-workflows-802592661.html


From any issue you can click on View Workflow to see the one used by the JENKINS project (it is a bit complex, I don't know if it is a default one or if it was already customised)
 


We just need to clarify for everyone what those statuses mean (if they are not self evident)
On Fri 20 Jan 2017 at 00:21, Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[hidden email]> wrote:
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


In my case, I'm one maintainer with 400+ bugs assigned across the two plugins I maintain.  If someone assigns all the bugs for the git plugin and the git client plugin to me, "assignee" will no longer be a useful field to me and I will ignore it.  I already ignore severity and several other fields, so that isn't a big problem.  I'd then maintain a record of my "working set" somewhere else.  It will probably be less visible to others, since I won't necessarily try to use Jira to maintain it.  I'm fine with maintaining my "working set" elsewhere, I only use Jira for the working set because I'm already there reading bug reports.

I acknowledge that I'm an exception (since the git plugin and the git client plugin are second only to the Subversion plugin in the total count of bugs open against them), but since Jesse noted that others use the same assignment process which I use, I may not be as much of an exception as you think.

Thanks!
Mark Waite
 
Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:


> The outcome of a triage on a specific issue would be that the correct


> component(s) and assignee were there.





Do we really need to set an assignee? For example for most


`{workflow,pipeline}-*-plugin` components there is intentionally no


default assignee. If and when someone intends to work on a fix, they


can assign to themselves.




As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 


--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.












--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.


For more options, visit https://groups.google.com/d/optout.











--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.


--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwGf466pLG_mnRQ8e0jYGB%2B%3DX-pOKpwfo32dDixnUbhSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
-----
Arnaud Héritier
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU--SJ99WOwm%3DD%3DdYC64u5gQOBjcSXh6vgxYhuKs8SPAjAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

stephenconnolly
In reply to this post by Ulli Hafner


On 20 January 2017 at 10:29, Ullrich Hafner <[hidden email]> wrote:

Am 20.01.2017 um 08:16 schrieb Stephen Connolly <[hidden email]>:

I also would love if we cleared out the assignee setting entirely.

How do we identify who is responsible for the issue (or who is the owner)? If there is no assignee then nobody gets notified about new bug reports or issue updates (if you are not watching an issue).


There are loads of plugins were somebody else has taken up (great) but I still get assigned the issue.


Then we should set the default assignee accordingly.

I'd rather use assignee to track actually picking up the issue. Status to track triage state.

Esp in credentials (which I have been repeatedly and actively scrubbing) use of assignee also helps identify when somebody starts working on the issue.

There is a status in progress which we have activated in Jira for such a use case.


Ideally the status would have a state to indicate that the JIRA has been accepted as a bug.

This makes sense. Currently we have no idea if a developer has accepted a bug report as valid. Since no assignee is attached to most of the new issues the reporter has no clue to see if the bug has been recognized or not. 

We are using in several other projects an additional initial Jira status ’New’. This status indicates that the bug has been created, but it has not yet been confirmed by the developer team that it is valid. From ‚New‘ there is a transition to ‚Open‘: this transition can be used by our new triage team to indicate that the issue has been reviewed and accepted as a bug. This transition should only be started if the issue is reproducible and if all information are provided. The triage team then could have a filter on all ’New’ issues to see what needs to be reviewed.  
 

Another status to indicate that it is ready to be worked on would be awesome

'In Progress' is already available: https://confluence.atlassian.com/adminjiraserver071/working-with-workflows-802592661.html


`In Progress` != `Plugin maintainer has blessed this issue as one that somebody can pick up`

Rather `In Progress` means - to me - that somebody is actually working on it  

We just need to clarify for everyone what those statuses mean (if they are not self evident)
On Fri 20 Jan 2017 at 00:21, Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[hidden email]> wrote:
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


In my case, I'm one maintainer with 400+ bugs assigned across the two plugins I maintain.  If someone assigns all the bugs for the git plugin and the git client plugin to me, "assignee" will no longer be a useful field to me and I will ignore it.  I already ignore severity and several other fields, so that isn't a big problem.  I'd then maintain a record of my "working set" somewhere else.  It will probably be less visible to others, since I won't necessarily try to use Jira to maintain it.  I'm fine with maintaining my "working set" elsewhere, I only use Jira for the working set because I'm already there reading bug reports.

I acknowledge that I'm an exception (since the git plugin and the git client plugin are second only to the Subversion plugin in the total count of bugs open against them), but since Jesse noted that others use the same assignment process which I use, I may not be as much of an exception as you think.

Thanks!
Mark Waite
 
Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:


> The outcome of a triage on a specific issue would be that the correct


> component(s) and assignee were there.





Do we really need to set an assignee? For example for most


`{workflow,pipeline}-*-plugin` components there is intentionally no


default assignee. If and when someone intends to work on a fix, they


can assign to themselves.




As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 


--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.












--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.


For more options, visit https://groups.google.com/d/optout.











--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.


--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwGf466pLG_mnRQ8e0jYGB%2B%3DX-pOKpwfo32dDixnUbhSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw0OH2Wb9gz-dRVNTFX%2BUh5Oa7gpZrC%2B7Xd15W0u6cfvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Ulli Hafner
I see, the discussion seems to indicate that we have (at least two) different kind of development processes. I’m not sure if I can summarize it properly:

We have plugins with one main developer who takes the responsibility for all new issues. Even if the issue is not solved immediately these issues should be assigned here to the component lead (which should be a good practice to set via the IRC bot anyway) to mark the responsible person for this issue. 

Then we have plugins (and core?) with one or more developers: here nobody is responsible for an issue in the beginning. If there is time for fixing an issue available then a team member is picking an interesting issue with no assignee, assigns the issue and starts work on it. All unassigned issues are waiting to be fixed by either a team member *or* a volunteer.

So I think the only way to make a bug reporter think that somebody really cares about an issue is to introduce this new status in the beginning (before Open). Then the triage team or the component lead can verify this issue and ping the reporter for additional information. If this issue will be finally accepted then it is moved to Open. In this step we can either remove the assignee or not (depending on the component lead). Then the reporter sees that his bug report has been accepted: if there is no assignee set, then the reporter also sees that nobody yet has the time to fix it and it would be good to provide a PR by someone else (including the reporter). 

 

Am 20.01.2017 um 14:39 schrieb Stephen Connolly <[hidden email]>:



On 20 January 2017 at 10:29, Ullrich Hafner <[hidden email]> wrote:

Am 20.01.2017 um 08:16 schrieb Stephen Connolly <[hidden email]>:

I also would love if we cleared out the assignee setting entirely.

How do we identify who is responsible for the issue (or who is the owner)? If there is no assignee then nobody gets notified about new bug reports or issue updates (if you are not watching an issue).


There are loads of plugins were somebody else has taken up (great) but I still get assigned the issue.


Then we should set the default assignee accordingly.

I'd rather use assignee to track actually picking up the issue. Status to track triage state.

Esp in credentials (which I have been repeatedly and actively scrubbing) use of assignee also helps identify when somebody starts working on the issue.

There is a status in progress which we have activated in Jira for such a use case.


Ideally the status would have a state to indicate that the JIRA has been accepted as a bug.

This makes sense. Currently we have no idea if a developer has accepted a bug report as valid. Since no assignee is attached to most of the new issues the reporter has no clue to see if the bug has been recognized or not. 

We are using in several other projects an additional initial Jira status ’New’. This status indicates that the bug has been created, but it has not yet been confirmed by the developer team that it is valid. From ‚New‘ there is a transition to ‚Open‘: this transition can be used by our new triage team to indicate that the issue has been reviewed and accepted as a bug. This transition should only be started if the issue is reproducible and if all information are provided. The triage team then could have a filter on all ’New’ issues to see what needs to be reviewed.  
 

Another status to indicate that it is ready to be worked on would be awesome

'In Progress' is already available: https://confluence.atlassian.com/adminjiraserver071/working-with-workflows-802592661.html


`In Progress` != `Plugin maintainer has blessed this issue as one that somebody can pick up`

Rather `In Progress` means - to me - that somebody is actually working on it  

We just need to clarify for everyone what those statuses mean (if they are not self evident)
On Fri 20 Jan 2017 at 00:21, Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[hidden email]> wrote:
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


In my case, I'm one maintainer with 400+ bugs assigned across the two plugins I maintain.  If someone assigns all the bugs for the git plugin and the git client plugin to me, "assignee" will no longer be a useful field to me and I will ignore it.  I already ignore severity and several other fields, so that isn't a big problem.  I'd then maintain a record of my "working set" somewhere else.  It will probably be less visible to others, since I won't necessarily try to use Jira to maintain it.  I'm fine with maintaining my "working set" elsewhere, I only use Jira for the working set because I'm already there reading bug reports.

I acknowledge that I'm an exception (since the git plugin and the git client plugin are second only to the Subversion plugin in the total count of bugs open against them), but since Jesse noted that others use the same assignment process which I use, I may not be as much of an exception as you think.

Thanks!
Mark Waite
 
Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:


> The outcome of a triage on a specific issue would be that the correct


> component(s) and assignee were there.





Do we really need to set an assignee? For example for most


`{workflow,pipeline}-*-plugin` components there is intentionally no


default assignee. If and when someone intends to work on a fix, they


can assign to themselves.




As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 


--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







-- 


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







-- 


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.












-- 


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.


For more options, visit https://groups.google.com/d/optout.











-- 


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.


-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwGf466pLG_mnRQ8e0jYGB%2B%3DX-pOKpwfo32dDixnUbhSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com.

For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw0OH2Wb9gz-dRVNTFX%2BUh5Oa7gpZrC%2B7Xd15W0u6cfvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56A2B757-0333-4BD0-B5BF-B07BA0DB16A4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Baptiste MATHUS
+1 for no assignee by default and adding the NEW status

Having a state to basically say: "this is issue is new, but has not been reviewed, so may be invalid/incomplete/whatever for whatever reason" makes sense IMO. And that the Triage team could use for, well, triaging.

Also, I'm trying to think about what the "default assignee" way of working right sends as message. It may push back some ppl willing to contribute, or "send" the wrong message with essentially newcomers (which are probably the majority) thinking basically when seeing an assignee "cool, someone is looking into that" which is generally (90% of the time?) wrong.

I love the idea of the TRIAGE team, thanks a lot Slide for that. I will try to help a bit (though I should already start by being back to more activity on the HOSTING project front).

2017-01-21 0:32 GMT+01:00 Ullrich Hafner <[hidden email]>:
I see, the discussion seems to indicate that we have (at least two) different kind of development processes. I’m not sure if I can summarize it properly:

We have plugins with one main developer who takes the responsibility for all new issues. Even if the issue is not solved immediately these issues should be assigned here to the component lead (which should be a good practice to set via the IRC bot anyway) to mark the responsible person for this issue. 

Then we have plugins (and core?) with one or more developers: here nobody is responsible for an issue in the beginning. If there is time for fixing an issue available then a team member is picking an interesting issue with no assignee, assigns the issue and starts work on it. All unassigned issues are waiting to be fixed by either a team member *or* a volunteer.

So I think the only way to make a bug reporter think that somebody really cares about an issue is to introduce this new status in the beginning (before Open). Then the triage team or the component lead can verify this issue and ping the reporter for additional information. If this issue will be finally accepted then it is moved to Open. In this step we can either remove the assignee or not (depending on the component lead). Then the reporter sees that his bug report has been accepted: if there is no assignee set, then the reporter also sees that nobody yet has the time to fix it and it would be good to provide a PR by someone else (including the reporter). 

 

Am 20.01.2017 um 14:39 schrieb Stephen Connolly <[hidden email]>:



On 20 January 2017 at 10:29, Ullrich Hafner <[hidden email]> wrote:

Am 20.01.2017 um 08:16 schrieb Stephen Connolly <[hidden email]>:

I also would love if we cleared out the assignee setting entirely.

How do we identify who is responsible for the issue (or who is the owner)? If there is no assignee then nobody gets notified about new bug reports or issue updates (if you are not watching an issue).


There are loads of plugins were somebody else has taken up (great) but I still get assigned the issue.


Then we should set the default assignee accordingly.

I'd rather use assignee to track actually picking up the issue. Status to track triage state.

Esp in credentials (which I have been repeatedly and actively scrubbing) use of assignee also helps identify when somebody starts working on the issue.

There is a status in progress which we have activated in Jira for such a use case.


Ideally the status would have a state to indicate that the JIRA has been accepted as a bug.

This makes sense. Currently we have no idea if a developer has accepted a bug report as valid. Since no assignee is attached to most of the new issues the reporter has no clue to see if the bug has been recognized or not. 

We are using in several other projects an additional initial Jira status ’New’. This status indicates that the bug has been created, but it has not yet been confirmed by the developer team that it is valid. From ‚New‘ there is a transition to ‚Open‘: this transition can be used by our new triage team to indicate that the issue has been reviewed and accepted as a bug. This transition should only be started if the issue is reproducible and if all information are provided. The triage team then could have a filter on all ’New’ issues to see what needs to be reviewed.  
 

Another status to indicate that it is ready to be worked on would be awesome

'In Progress' is already available: https://confluence.atlassian.com/adminjiraserver071/working-with-workflows-802592661.html


`In Progress` != `Plugin maintainer has blessed this issue as one that somebody can pick up`

Rather `In Progress` means - to me - that somebody is actually working on it  

We just need to clarify for everyone what those statuses mean (if they are not self evident)
On Fri 20 Jan 2017 at 00:21, Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[hidden email]> wrote:
I think this is not the common practice. Wouldn’t it be better to use the in progress transition for such issues?

When I create an issue and see that there is no assignee it gives me the feeling that I should not have spent the time in creating the issue since nobody actually is interested in fixing it (or responding to it). (As a user I don’t know that the component owner does use the assignee field differently then the rest.) 


In my case, I'm one maintainer with 400+ bugs assigned across the two plugins I maintain.  If someone assigns all the bugs for the git plugin and the git client plugin to me, "assignee" will no longer be a useful field to me and I will ignore it.  I already ignore severity and several other fields, so that isn't a big problem.  I'd then maintain a record of my "working set" somewhere else.  It will probably be less visible to others, since I won't necessarily try to use Jira to maintain it.  I'm fine with maintaining my "working set" elsewhere, I only use Jira for the working set because I'm already there reading bug reports.

I acknowledge that I'm an exception (since the git plugin and the git client plugin are second only to the Subversion plugin in the total count of bugs open against them), but since Jesse noted that others use the same assignment process which I use, I may not be as much of an exception as you think.

Thanks!
Mark Waite
 
Am 19.01.2017 um 20:50 schrieb Slide <[hidden email]>:

If that is a common practice, then we can skip setting the assignee and focus on component assignment and reproducibility, or we can have a "whitelist" of plugins that we set assignee for. The goal isn't to make things harder for maintainers, we want to help as much as possible by funneling things to the correct place. If there is something else that would be more helpful, or an additional scope, please bring it up. 

On Thu, Jan 19, 2017 at 12:48 PM Mark Waite <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[hidden email]> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <[hidden email]> wrote:


> The outcome of a triage on a specific issue would be that the correct


> component(s) and assignee were there.





Do we really need to set an assignee? For example for most


`{workflow,pipeline}-*-plugin` components there is intentionally no


default assignee. If and when someone intends to work on a fix, they


can assign to themselves.




As further support for what Jesse says, please don't assign me as an owner for bugs in the git plugin or the git client plugin during the triage process, unless you're willing to accept that I'll immediately remove that assignment and return them to "Unassigned".

I only assign bugs to myself when I want to indicate that I'm working on them, or intending to work on them "soon".  I use the list of bugs assigned to me as a reminder of active work, not as another way of expressing the component name.

Mark Waite


 


--


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDOCNjio86-TbQ%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







-- 


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.







-- 


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.












-- 


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com.


For more options, visit https://groups.google.com/d/optout.











-- 


You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.


To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.


-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwGf466pLG_mnRQ8e0jYGB%2B%3DX-pOKpwfo32dDixnUbhSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com.

For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw0OH2Wb9gz-dRVNTFX%2BUh5Oa7gpZrC%2B7Xd15W0u6cfvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56A2B757-0333-4BD0-B5BF-B07BA0DB16A4%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6SETyf1-Jit0vny_pv0KsNtpt%3DijtOBqoNG2E6isUDWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Daniel Beck

> On 21.01.2017, at 15:07, Baptiste Mathus <[hidden email]> wrote:
>
> adding the NEW status
>
> Having a state to basically say: "this is issue is new, but has not been reviewed, so may be invalid/incomplete/whatever for whatever reason" makes sense IMO.

Shouldn't we create a new "To Do" or "Confirmed" status then, to initialize all existing issues that aren't in progress etc. to that unverified status?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9C189939-804F-40FB-B19F-2EF43E6EC357%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage "Team"

Ulli Hafner
I would prefer to use the default Jira workflow as much as possible. So adding a new start state would be much simpler. No other transition needs to be changed in this case.

> Am 21.01.2017 um 23:18 schrieb Daniel Beck <[hidden email]>:
>
>
>> On 21.01.2017, at 15:07, Baptiste Mathus <[hidden email]> wrote:
>>
>> adding the NEW status
>>
>> Having a state to basically say: "this is issue is new, but has not been reviewed, so may be invalid/incomplete/whatever for whatever reason" makes sense IMO.
>
> Shouldn't we create a new "To Do" or "Confirmed" status then, to initialize all existing issues that aren't in progress etc. to that unverified status?
>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9C189939-804F-40FB-B19F-2EF43E6EC357%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8C8FA5DF-8CEA-4F3C-8599-F76C9C53BD22%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
123