2017-01-24 1:11 GMT+01:00 Mark Waite <[email protected]>: > > > On Mon, Jan 23, 2017 at 3:06 PM Ullrich Hafner <[email protected]> > wrote: > >> Am 21.01.2017 um 15:07 schrieb Baptiste Mathus <[email protected]>: >> >> +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, >> >> >> Why would this push back people? A default assignee (as Atlassian defines >> it) is a person who is responsible for an issue, i.e. the owner (not >> identical to the person fixing it). >> > > I mistakenly assumed that "assignee" meant "the person who is working on > this bug" or at least "the person who will eventually work on this bug". > When a bug was assigned to someone, I was hesitant to start work on that > bug without acknowledgment from the current assignee that they are not > actively working on the bug. If the bug is unassigned, then I am more > confident that no one is actively working on that bug. >
+1. I said that not only out of thin air, but because this is how I started. And seeing an assignee adds a step of commenting on the issue, if I ever dared, then waiting for the answer to take over it. Possibly granted, I would work on it still if blocking, but wouldn't assign it to myself directly generally. > > I think I can get the same information from reports if I can trust that > people use the state "In Progress" to indicate they are actively working on > a bug. I'm happy to start using "In Progress" as well. There are > currently 574 bugs "In Progress", with approximately 10% of them updated in > the last month. Based on that, "In Progress" does not seem to be a widely > used status value. > > Can you provide a pointer to that Atlassian definition of "assignee"? I'd > like to understand their intended use model. > > Likewise, can you further expand on your definition of "responsible for an > issue"? > > Is "responsible for an issue" > > - the lead maintainer of the component? > - the person implementing the fix? > - the person verifying the fix? > - the person checking the bug can be duplicated? > - the person automating tests of the bug? > > > 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 think the opposite message is also wrong: ohh, no assignee, that means >> nobody cares about my bug report:-( I think the majority of users reporting >> a bug is not interested in fixing it on their own. >> (And a side note: as a user of a professional software system (especially >> one that is used to improve the quality of software) I would expect that >> most of the issues are going to be solved by the team, not only 10%. But >> this would be a topic for another discussion: how can we close the gap >> between new and resolved issues...) >> >> > I disagree that "most of the issues are going to be solved by the team", > unless you and I have radically different definitions of "team". I define > "team" as "active maintainers of that plugin", which makes the number of > people quite small. I hope that many, many issues are investigated and > resolved by a wide collection of infrequent contributors who discover and > fix something important to them. > Agree with Mark. I was going to answer I disagree too on opensource, clearly: I am not committed to fix *any* thing that might arise on the opensource plugins I maintain. And then, anyway, thinking on the professional side, I would say this is actually the same: which company fixes *everything*, even when full time? Actual bugs with high severity, sure, but all that long trail on non blocking "issues" (not even bugs, often) have a very low chance to get worked on any day. And this is fine, because this is also a matter of product management. But I'm drifting here. > > Mark Waite > >> >> 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 <[email protected]>: >> >> 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 < >> [email protected]>: >> >> >> >> 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). >> >> >> 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 <[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/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 [email protected]. >> >> >> To view this discussion on the web visit https://groups.google. >> com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA- >> pCibkzfOkkU2P%2BzUNrdqV0H43w%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/msgid/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/msgid/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/msgid/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/msgid/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/msgid/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%2BnPnMw0OH2Wb9gz-dRVNTFX% >> 2BUh5Oa7gpZrC%2B7Xd15W0u6cfvg%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw0OH2Wb9gz-dRVNTFX%2BUh5Oa7gpZrC%2B7Xd15W0u6cfvg%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/ >> msgid/jenkinsci-dev/56A2B757-0333-4BD0-B5BF-B07BA0DB16A4%40gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/56A2B757-0333-4BD0-B5BF-B07BA0DB16A4%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/CANWgJS6SETyf1-Jit0vny_pv0KsNtpt% >> 3DijtOBqoNG2E6isUDWA%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6SETyf1-Jit0vny_pv0KsNtpt%3DijtOBqoNG2E6isUDWA%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/ >> msgid/jenkinsci-dev/899E86B0-CB76-4F38-94FE-B588C5FF131F%40gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/899E86B0-CB76-4F38-94FE-B588C5FF131F%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/CAO49JtFKis8eO0YH0a4TH%2Bp% > 3DMWmVESAkcpbqeag_LjF3AXBXQg%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFKis8eO0YH0a4TH%2Bp%3DMWmVESAkcpbqeag_LjF3AXBXQg%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/msgid/jenkinsci-dev/CANWgJS5ft%2BN2D6bdg_ai-6L0HFRpsfGCJ0fyPsBKRBOWOLwh0Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
