> Am 20.01.2017 um 01:21 schrieb Mark Waite <[email protected]>:
> 
> 
> 
> 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 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 <[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>.

-- 
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/24E5796E-EB38-45D5-B9F3-580078345485%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to