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 < [email protected]> wrote: > On 20 January 2017 at 10:29, Ullrich Hafner <[email protected]> > wrote: > >> >> Am 20.01.2017 um 08:16 schrieb Stephen Connolly < >> [email protected]>: >> >> 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 <[email protected]> >> wrote: >> >>> On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[email protected]> >>> 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 <[email protected]>: >>> >>> 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 <[email protected]> >>> wrote: >>> >>> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[email protected]> >>> wrote: >>> >>> On Thu, Jan 19, 2017 at 12:34 PM, Slide <[email protected]> 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 [email protected]. >>> >>> >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/jenkinsci-dev/CANfRfr0SRoe%2BWirJPscSjeLb_kXszYVFxTqpQDO >>> CNjio86-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 [email protected]. >>> >>> >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2Bz >>> UNrdqV0H43w%40mail.gmail.com >>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> 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 [email protected]. >>> >>> >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_ >>> zpt_Yg3XC9%2BbuA%40mail.gmail.com >>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfcK4R8i4W%3DGs8mW94Agzn5jdyudQk_zpt_Yg3XC9%2BbuA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> 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 [email protected]. >>> >>> >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com >>> <https://groups.google.com/d/msgid/jenkinsci-dev/4C16E3F0-8F9D-43F2-854B-C2E0FD29D6D2%40gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> 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 [email protected]. >>> >>> >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B- >>> AZseAH%2B-dpkcaNqCmng%40mail.gmail.com >>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE685zds-5QdsWhWR59%3D_MmL%2B-AZseAH%2B-dpkcaNqCmng%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> 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 [email protected]. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/jenkinsci-dev/CA%2BnPnMwGf466pLG_mnRQ8e0jYGB%2B%3DX- >> pOKpwfo32dDixnUbhSg%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwGf466pLG_mnRQ8e0jYGB%2B%3DX-pOKpwfo32dDixnUbhSg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> 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 [email protected]. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com?utm_medium=email&utm_source=footer> >> . >> >> 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 [email protected]. 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.
