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

> 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 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] 
> <mailto:[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] <mailto:[email protected]>>:
>> 
>> 
>> 
>> On 20 January 2017 at 10:29, Ullrich Hafner <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>>> Am 20.01.2017 um 08:16 schrieb Stephen Connolly 
>>> <[email protected] <mailto:[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
>>  
>> <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] 
>>> <mailto:[email protected]>> wrote:
>>> On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <[email protected] 
>>> <mailto:[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] 
>>>> <mailto:[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] 
>>>> <mailto:[email protected]>> wrote:
>>>> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> On Thu, Jan 19, 2017 at 12:34 PM, Slide <[email protected] 
>>>> <mailto:[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] 
>>>> <mailto:jenkinsci-dev%[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
>>>>  
>>>> <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 
>>>> <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] 
>>>> <mailto:[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 
>>>> <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] 
>>>> <mailto:[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 
>>>> <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] 
>>> <mailto:[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 
>>> <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] 
>>> <mailto:[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 
>>> <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] 
>>> <mailto:[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 
>>> <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] 
>> <mailto:[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 
>> <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] 
>> <mailto:[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 
>> <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] 
> <mailto:[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 
> <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] 
> <mailto:[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 
> <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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to