Re: Bug Triage "Team"

[Oleg Nenashev]

Hi all,

I have started assembling the Jenkins core triage tooling and 
documentation. It includes the existing triage boards (thanks to Daniel!), 
community ratings and other tools we have. I also started on a new dashboard 
 
specifically dedicated to the triage of the Jenkins core and included 
components in recent releases. This dashboard is somewhat similar to Core 
Maintainers Attention 
 by 
Daniel, but it rather focuses on triaging new issues. Hence I want to list 
"recent reported issues without response" and other similar listings, 
assuming that we can build something feasible with the default Jira plugins 
(e.g. no "commentsCount" query). It would also include some statistics. Any 
feedback and suggestions are welcome!

One of items in CII certification is that "The project MUST acknowledge a 
majority of bug reports submitted in the last 2-12 months (inclusive); the 
response need not include a fix". In our current Jira flow for the Jenkins 
core we do not really "acknowledge" bugs in any means. It would be useful 
for users, because they could easily discover whether a defect is confirmed 
or not. We could do one of the following:

   - Low-cost: consider all issues with one comment as "acknowledged". It 
   is not actually a case, half of my first comments ask for more data and/or 
   reference https://www.jenkins.io/participate/report-issue/
   - Low-cost: add a "triaged"/"confirmed" label to the default triage 
   process so that all reviewed issues are marked accordingly if they are 
   confirmed
   - High-cost: Update the workflow so that all bugs start from the 
   "Untriaged" state and get moved to "Open" only once acknowledged

Would appreciate suggestions about how to approach that.

P.S: Our statistics for the last year is not that bad, but we could 
definitely do better:



Thanks in advance,
Oleg


On Tuesday, June 16, 2020 at 11:22:30 PM UTC+2, Vlad Silverman wrote:
>
> I would be interested
>
> On Jun 16, 2020, at 2:07 PM, Mark Waite > 
> wrote:
>
> I'm interested.
>
> On Tue, Jun 16, 2020 at 2:22 PM Oleg Nenashev  > wrote:
>
>> Hi all,
>>
>> I would like to recover this thread. As a part of the CDF graduation 
>> criteria, we are expected to pass the Core Infrastructure Initiative 
>> checklist. There is a thread about it here 
>> 
>> .
>> According to the CII criteria for issue reporting 
>> 
>> , 
>>
>>- The project MUST acknowledge a majority of bug reports submitted in 
>>the last 2-12 months (inclusive); the response need not include a fix
>>- The project SHOULD respond to a majority (>50%) of enhancement 
>>requests in the last 2-12 months (inclusive).
>>
>> Under this criteria the "project" means the Jenkins core and its 
>> components, our current certification process 
>>  does not 
>> include plugins. I did some queries in Jira. We are somewhat compliant with 
>> the first criteria (thanks to Daniel Beck and other contributors who 
>> occasionally scrub issues), but not with the second one.
>>
>> In order to hit the goal, I think we need to discuss starting the triage 
>> team as it was proposed by Alex Earl, and maybe introducing a formal 
>> process for acknowledging defects (e.g. "confirmed" label). Would anyone be 
>> interested to participate?
>>
>> Best regards,
>> Oleg
>>
>>
>>
>> On Sunday, December 16, 2018 at 1:05:08 PM UTC+1, Oleg Nenashev wrote:
>>>
>>> Hi all,
>>>
>>> Over last years I have been triaging incoming JIRA issues in the JENKINS 
>>> project together with several other contributors. I was also a default 
>>> assignee in the “_unsorted 
>>> ”
>>>  
>>> JIRA component which was suggested by default in the issue creation screen. 
>>> Currently there are around 500 issues in the component, and I suspect I 
>>> processed hundreds of JIRA issues and assigned them to proper components 
>>> since the _unsorted was introduced.
>>>
>>> As some of the Jenkins contributors already know, I will have a very 
>>> limited availability in the community over the next several months 
>>> (personal matters). I will be unable to provide a timely response in the 
>>> tickets. I would like to ensure that I do not become a bottleneck in the 
>>> issue triage process.
>>>
>>>- Several days ago I removed the default assignee in *_unsorted* and 
>>>unassigned the rest of open tickets
>>>- There are only 40 open tickets 
>>>   
>>> 
>>>  
>>>   now, many 

Re: Bug Triage "Team"

[Vlad Silverman]

I would be interested

> On Jun 16, 2020, at 2:07 PM, Mark Waite  wrote:
> 
> I'm interested.
> 
> On Tue, Jun 16, 2020 at 2:22 PM Oleg Nenashev  > wrote:
> Hi all,
> 
> I would like to recover this thread. As a part of the CDF graduation 
> criteria, we are expected to pass the Core Infrastructure Initiative 
> checklist. There is a thread about it here 
> .
> According to the CII criteria for issue reporting 
> , 
> The project MUST acknowledge a majority of bug reports submitted in the last 
> 2-12 months (inclusive); the response need not include a fix
> The project SHOULD respond to a majority (>50%) of enhancement requests in 
> the last 2-12 months (inclusive).
> Under this criteria the "project" means the Jenkins core and its components, 
> our current certification process 
>  does not 
> include plugins. I did some queries in Jira. We are somewhat compliant with 
> the first criteria (thanks to Daniel Beck and other contributors who 
> occasionally scrub issues), but not with the second one.
> 
> In order to hit the goal, I think we need to discuss starting the triage team 
> as it was proposed by Alex Earl, and maybe introducing a formal process for 
> acknowledging defects (e.g. "confirmed" label). Would anyone be interested to 
> participate?
> 
> Best regards,
> Oleg
> 
> 
> 
> On Sunday, December 16, 2018 at 1:05:08 PM UTC+1, Oleg Nenashev wrote:
> Hi all,
> 
> Over last years I have been triaging incoming JIRA issues in the JENKINS 
> project together with several other contributors. I was also a default 
> assignee in the “_unsorted 
> ”
>  JIRA component which was suggested by default in the issue creation screen. 
> Currently there are around 500 issues in the component, and I suspect I 
> processed hundreds of JIRA issues and assigned them to proper components 
> since the _unsorted was introduced.
> 
> As some of the Jenkins contributors already know, I will have a very limited 
> availability in the community over the next several months (personal 
> matters). I will be unable to provide a timely response in the tickets. I 
> would like to ensure that I do not become a bottleneck in the issue triage 
> process.
> Several days ago I removed the default assignee in _unsorted and unassigned 
> the rest of open tickets
> There are only 40 open tickets 
> 
>  now, many of them can be actually closed
> This component has explicit disclaimer that there is NO response ETA, and I 
> was not able to process all requests there. I welcome anybody to become a 
> default assignee there, e.g. on a rotation basis.
> Next week I will stop triaging incoming issues in the Jenkins core
> I used to take a look at new issues every few days after I started 
> maintaining the Jenkins core (regressions, misreported high-severity issues), 
> but it is not sustainable going forward
> I will also stop triaging issues in plugins I used to maintain and then 
> marked for adoption, but which have not been adopted yet
> Examples: EnvInject , Mask Passwords 
> , Release 
> , Periodic Backup 
> , etc.
> Thanks a lot to everybody who contributes to the issue triage in Jenkins JIRA!
> 
> Best regards,
> Oleg
> 
> 
> 
> On Tuesday, April 11, 2017 at 6:49:42 PM UTC+2, slide wrote:
> Any time that people can give is great. Even a spare 10 minutes here and 
> there would be helpful if you spread it across a large number of people.
> 
> On Tue, Apr 11, 2017 at 4:01 AM Mark Waite > wrote:
> My situation is similar to Oleg's.  My first priority is to review bugs 
> submitted against the plugins I maintain, and to reproduce bugs for those 
> plugins, and to create automated environments to reproduce those bugs.  
> Helping with other projects will come as a second priority.
> 
> Mark Waite
> 
> On Tue, Apr 11, 2017 at 3:13 AM Oleg Nenashev > wrote:
> Hi all,
> 
> I am in. 
> 
> Right now I dedicate time for reviewing incoming issues in the core, 
> Remoting, "_unsorted", a couple of other modules and a bunch of plugins I am 
> supposed to maintain. I can unlikely dedicate more time to review other 
> components (would prefer to do bugfixing in core/remoting), but at least I am 
> ready to keep working on the current stuff.
> 
> BR, Oleg
> 
> 2017-04-11 10:07 GMT+02:00 Daniel Beck >:
> 
> > On 10.04.2017, at 22:44, Slide > wrote:
> >
> > if you are interested!
> 
> I am.
> 
> --
> You received this 

Re: Bug Triage "Team"

[Mark Waite]

I'm interested.

On Tue, Jun 16, 2020 at 2:22 PM Oleg Nenashev 
wrote:

> Hi all,
>
> I would like to recover this thread. As a part of the CDF graduation
> criteria, we are expected to pass the Core Infrastructure Initiative
> checklist. There is a thread about it here
> 
> .
> According to the CII criteria for issue reporting
> 
> ,
>
>- The project MUST acknowledge a majority of bug reports submitted in
>the last 2-12 months (inclusive); the response need not include a fix
>- The project SHOULD respond to a majority (>50%) of enhancement
>requests in the last 2-12 months (inclusive).
>
> Under this criteria the "project" means the Jenkins core and its
> components, our current certification process
>  does not
> include plugins. I did some queries in Jira. We are somewhat compliant with
> the first criteria (thanks to Daniel Beck and other contributors who
> occasionally scrub issues), but not with the second one.
>
> In order to hit the goal, I think we need to discuss starting the triage
> team as it was proposed by Alex Earl, and maybe introducing a formal
> process for acknowledging defects (e.g. "confirmed" label). Would anyone be
> interested to participate?
>
> Best regards,
> Oleg
>
>
>
> On Sunday, December 16, 2018 at 1:05:08 PM UTC+1, Oleg Nenashev wrote:
>>
>> Hi all,
>>
>> Over last years I have been triaging incoming JIRA issues in the JENKINS
>> project together with several other contributors. I was also a default
>> assignee in the “_unsorted
>> ”
>> JIRA component which was suggested by default in the issue creation screen.
>> Currently there are around 500 issues in the component, and I suspect I
>> processed hundreds of JIRA issues and assigned them to proper components
>> since the _unsorted was introduced.
>>
>> As some of the Jenkins contributors already know, I will have a very
>> limited availability in the community over the next several months
>> (personal matters). I will be unable to provide a timely response in the
>> tickets. I would like to ensure that I do not become a bottleneck in the
>> issue triage process.
>>
>>- Several days ago I removed the default assignee in *_unsorted* and
>>unassigned the rest of open tickets
>>- There are only 40 open tickets
>>   
>> 
>>   now, many of them can be actually closed
>>   - This component has explicit disclaimer that there is NO response
>>   ETA, and I was not able to process all requests there. I welcome 
>> anybody to
>>   become a default assignee there, e.g. on a rotation basis.
>>- Next week I will stop triaging incoming issues in the Jenkins core
>>- I used to take a look at new issues every few days after I started
>>   maintaining the Jenkins core (regressions, misreported high-severity
>>   issues), but it is not sustainable going forward
>>- I will also stop triaging issues in plugins I used to maintain and
>>then marked for adoption, but which have not been adopted yet
>>   - Examples: EnvInject , Mask
>>   Passwords , Release
>>   , Periodic Backup
>>   , etc.
>>
>> Thanks a lot to everybody who contributes to the issue triage in Jenkins
>> JIRA!
>>
>> Best regards,
>> Oleg
>>
>>
>>
>> On Tuesday, April 11, 2017 at 6:49:42 PM UTC+2, slide wrote:
>>>
>>> Any time that people can give is great. Even a spare 10 minutes here and
>>> there would be helpful if you spread it across a large number of people.
>>>
>>> On Tue, Apr 11, 2017 at 4:01 AM Mark Waite  wrote:
>>>
 My situation is similar to Oleg's.  My first priority is to review bugs
 submitted against the plugins I maintain, and to reproduce bugs for those
 plugins, and to create automated environments to reproduce those bugs.
 Helping with other projects will come as a second priority.

 Mark Waite

 On Tue, Apr 11, 2017 at 3:13 AM Oleg Nenashev 
 wrote:

> Hi all,
>
> I am in.
>
> Right now I dedicate time for reviewing incoming issues in the core,
> Remoting, "_unsorted", a couple of other modules and a bunch of plugins I
> am supposed to maintain. I can unlikely dedicate more time to review other
> components (would prefer to do bugfixing in core/remoting), but at least I
> am ready to keep working on the current stuff.
>
> BR, Oleg
>
> 2017-04-11 10:07 GMT+02:00 Daniel Beck :
>

Re: Bug Triage "Team"

[Slide]

I'm definitely still interested in this. There wasn't a lot of interest
back in the day, so I kind of let it slide.

On Tue, Jun 16, 2020 at 1:29 PM Sladyn Nunes 
wrote:

> I would love to be able to help in bug triaging, I do not have a lot of
> experience, but would be interested in participating.
>
> On Wed, Jun 17, 2020, 1:56 AM Marky Jackson 
> wrote:
>
>> I would like to be a part of this. I have some operational knowledge of
>> bug-triage from the Kubernetes community that may be of some help here.
>>
>> > On Jun 16, 2020, at 1:22 PM, Oleg Nenashev 
>> wrote:
>> >
>>
>> --
>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/B2F5F599-8636-4551-9F0F-EE1D24B581EA%40gmail.com
>> .
>>
> --
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAC-Leqsk-AJKXTSu1e%2BoU%2BVKC5jGJGnCVNZ-KZ1CN7XhDjgPfw%40mail.gmail.com
> 
> .
>


-- 
Website: http://earl-of-code.com

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVd1KjF2vBz8qqNK6-%2BcudkyyfoxMj1ovn1%3Dnr5LP%3DMv9w%40mail.gmail.com.

Re: Bug Triage "Team"

[Sladyn Nunes]

I would love to be able to help in bug triaging, I do not have a lot of
experience, but would be interested in participating.

On Wed, Jun 17, 2020, 1:56 AM Marky Jackson 
wrote:

> I would like to be a part of this. I have some operational knowledge of
> bug-triage from the Kubernetes community that may be of some help here.
>
> > On Jun 16, 2020, at 1:22 PM, Oleg Nenashev 
> wrote:
> >
>
> --
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/B2F5F599-8636-4551-9F0F-EE1D24B581EA%40gmail.com
> .
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAC-Leqsk-AJKXTSu1e%2BoU%2BVKC5jGJGnCVNZ-KZ1CN7XhDjgPfw%40mail.gmail.com.

Re: Bug Triage "Team"

[Marky Jackson]

I would like to be a part of this. I have some operational knowledge of 
bug-triage from the Kubernetes community that may be of some help here.

> On Jun 16, 2020, at 1:22 PM, Oleg Nenashev  wrote:
> 

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/B2F5F599-8636-4551-9F0F-EE1D24B581EA%40gmail.com.

Re: Bug Triage "Team"

[Oleg Nenashev]

Hi all,

I would like to recover this thread. As a part of the CDF graduation 
criteria, we are expected to pass the Core Infrastructure Initiative 
checklist. There is a thread about it here 

.
According to the CII criteria for issue reporting 
, 

   - The project MUST acknowledge a majority of bug reports submitted in 
   the last 2-12 months (inclusive); the response need not include a fix
   - The project SHOULD respond to a majority (>50%) of enhancement 
   requests in the last 2-12 months (inclusive).

Under this criteria the "project" means the Jenkins core and its 
components, our current certification process 
 does not 
include plugins. I did some queries in Jira. We are somewhat compliant with 
the first criteria (thanks to Daniel Beck and other contributors who 
occasionally scrub issues), but not with the second one.

In order to hit the goal, I think we need to discuss starting the triage 
team as it was proposed by Alex Earl, and maybe introducing a formal 
process for acknowledging defects (e.g. "confirmed" label). Would anyone be 
interested to participate?

Best regards,
Oleg



On Sunday, December 16, 2018 at 1:05:08 PM UTC+1, Oleg Nenashev wrote:
>
> Hi all,
>
> Over last years I have been triaging incoming JIRA issues in the JENKINS 
> project together with several other contributors. I was also a default 
> assignee in the “_unsorted 
> ”
>  
> JIRA component which was suggested by default in the issue creation screen. 
> Currently there are around 500 issues in the component, and I suspect I 
> processed hundreds of JIRA issues and assigned them to proper components 
> since the _unsorted was introduced.
>
> As some of the Jenkins contributors already know, I will have a very 
> limited availability in the community over the next several months 
> (personal matters). I will be unable to provide a timely response in the 
> tickets. I would like to ensure that I do not become a bottleneck in the 
> issue triage process.
>
>- Several days ago I removed the default assignee in *_unsorted* and 
>unassigned the rest of open tickets
>- There are only 40 open tickets 
>   
> 
>  
>   now, many of them can be actually closed
>   - This component has explicit disclaimer that there is NO response 
>   ETA, and I was not able to process all requests there. I welcome 
> anybody to 
>   become a default assignee there, e.g. on a rotation basis. 
>- Next week I will stop triaging incoming issues in the Jenkins core
>- I used to take a look at new issues every few days after I started 
>   maintaining the Jenkins core (regressions, misreported high-severity 
>   issues), but it is not sustainable going forward
>- I will also stop triaging issues in plugins I used to maintain and 
>then marked for adoption, but which have not been adopted yet
>   - Examples: EnvInject , Mask 
>   Passwords , Release 
>   , Periodic Backup 
>   , etc.
>   
> Thanks a lot to everybody who contributes to the issue triage in Jenkins 
> JIRA!
>
> Best regards,
> Oleg
>
>
>
> On Tuesday, April 11, 2017 at 6:49:42 PM UTC+2, slide wrote:
>>
>> Any time that people can give is great. Even a spare 10 minutes here and 
>> there would be helpful if you spread it across a large number of people.
>>
>> On Tue, Apr 11, 2017 at 4:01 AM Mark Waite  wrote:
>>
>>> My situation is similar to Oleg's.  My first priority is to review bugs 
>>> submitted against the plugins I maintain, and to reproduce bugs for those 
>>> plugins, and to create automated environments to reproduce those bugs.  
>>> Helping with other projects will come as a second priority.
>>>
>>> Mark Waite
>>>
>>> On Tue, Apr 11, 2017 at 3:13 AM Oleg Nenashev  
>>> wrote:
>>>
 Hi all,

 I am in. 

 Right now I dedicate time for reviewing incoming issues in the core, 
 Remoting, "_unsorted", a couple of other modules and a bunch of plugins I 
 am supposed to maintain. I can unlikely dedicate more time to review other 
 components (would prefer to do bugfixing in core/remoting), but at least I 
 am ready to keep working on the current stuff.

 BR, Oleg

 2017-04-11 10:07 GMT+02:00 Daniel Beck :

>
> > On 10.04.2017, at 22:44, Slide  wrote:
> >
> > if you are interested!
>
> I am.
>

> --
> You received 

Re: Bug Triage "Team"

[Oleg Nenashev]

Hi all,

Over last years I have been triaging incoming JIRA issues in the JENKINS 
project together with several other contributors. I was also a default 
assignee in the “_unsorted 
”
 
JIRA component which was suggested by default in the issue creation screen. 
Currently there are around 500 issues in the component, and I suspect I 
processed hundreds of JIRA issues and assigned them to proper components 
since the _unsorted was introduced.

As some of the Jenkins contributors already know, I will have a very 
limited availability in the community over the next several months 
(personal matters). I will be unable to provide a timely response in the 
tickets. I would like to ensure that I do not become a bottleneck in the 
issue triage process.

   - Several days ago I removed the default assignee in *_unsorted* and 
   unassigned the rest of open tickets
   - There are only 40 open tickets 
  

 
  now, many of them can be actually closed
  - This component has explicit disclaimer that there is NO response 
  ETA, and I was not able to process all requests there. I welcome anybody 
to 
  become a default assignee there, e.g. on a rotation basis. 
   - Next week I will stop triaging incoming issues in the Jenkins core
   - I used to take a look at new issues every few days after I started 
  maintaining the Jenkins core (regressions, misreported high-severity 
  issues), but it is not sustainable going forward
   - I will also stop triaging issues in plugins I used to maintain and 
   then marked for adoption, but which have not been adopted yet
  - Examples: EnvInject , Mask 
  Passwords , Release 
  , Periodic Backup 
  , etc.
  
Thanks a lot to everybody who contributes to the issue triage in Jenkins 
JIRA!

Best regards,
Oleg



On Tuesday, April 11, 2017 at 6:49:42 PM UTC+2, slide wrote:
>
> Any time that people can give is great. Even a spare 10 minutes here and 
> there would be helpful if you spread it across a large number of people.
>
> On Tue, Apr 11, 2017 at 4:01 AM Mark Waite  > wrote:
>
>> My situation is similar to Oleg's.  My first priority is to review bugs 
>> submitted against the plugins I maintain, and to reproduce bugs for those 
>> plugins, and to create automated environments to reproduce those bugs.  
>> Helping with other projects will come as a second priority.
>>
>> Mark Waite
>>
>> On Tue, Apr 11, 2017 at 3:13 AM Oleg Nenashev > > wrote:
>>
>>> Hi all,
>>>
>>> I am in. 
>>>
>>> Right now I dedicate time for reviewing incoming issues in the core, 
>>> Remoting, "_unsorted", a couple of other modules and a bunch of plugins I 
>>> am supposed to maintain. I can unlikely dedicate more time to review other 
>>> components (would prefer to do bugfixing in core/remoting), but at least I 
>>> am ready to keep working on the current stuff.
>>>
>>> BR, Oleg
>>>
>>> 2017-04-11 10:07 GMT+02:00 Daniel Beck >:
>>>

 > On 10.04.2017, at 22:44, Slide > 
 wrote:
 >
 > if you are interested!

 I am.

>>>
 --
 You received this message because you are subscribed to a topic in the 
 Google Groups "Jenkins Developers" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/jenkinsci-dev/XToix3QpL_k/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to 
 jenkinsci-de...@googlegroups.com .

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/2F5B15D7-B147-4F4B-B8CE-04760B1F9A7D%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 jenkinsci-de...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAypc6o5YBYDAVNKqD0euqGhLJ%2B-Z929s8fkZU51ZZv%2BA%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 jenkinsci-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> 

Re: Bug Triage "Team"

[Slide]

Any time that people can give is great. Even a spare 10 minutes here and
there would be helpful if you spread it across a large number of people.

On Tue, Apr 11, 2017 at 4:01 AM Mark Waite 
wrote:

> My situation is similar to Oleg's.  My first priority is to review bugs
> submitted against the plugins I maintain, and to reproduce bugs for those
> plugins, and to create automated environments to reproduce those bugs.
> Helping with other projects will come as a second priority.
>
> Mark Waite
>
> On Tue, Apr 11, 2017 at 3:13 AM Oleg Nenashev 
> wrote:
>
> Hi all,
>
> I am in.
>
> Right now I dedicate time for reviewing incoming issues in the core,
> Remoting, "_unsorted", a couple of other modules and a bunch of plugins I
> am supposed to maintain. I can unlikely dedicate more time to review other
> components (would prefer to do bugfixing in core/remoting), but at least I
> am ready to keep working on the current stuff.
>
> BR, Oleg
>
> 2017-04-11 10:07 GMT+02:00 Daniel Beck :
>
>
> > On 10.04.2017, at 22:44, Slide  wrote:
> >
> > if you are interested!
>
> I am.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/XToix3QpL_k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/2F5B15D7-B147-4F4B-B8CE-04760B1F9A7D%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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAypc6o5YBYDAVNKqD0euqGhLJ%2B-Z929s8fkZU51ZZv%2BA%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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHqHF8aboPTWkGQYx%2BF_qCHPd2bMGZ8HChVauPuk6NbGQ%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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfbWcwsZGyA4N1BEp_XiE%2Byb7_caP674h_-HyA8fmgFCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug Triage "Team"

[Mark Waite]

My situation is similar to Oleg's.  My first priority is to review bugs
submitted against the plugins I maintain, and to reproduce bugs for those
plugins, and to create automated environments to reproduce those bugs.
Helping with other projects will come as a second priority.

Mark Waite

On Tue, Apr 11, 2017 at 3:13 AM Oleg Nenashev 
wrote:

> Hi all,
>
> I am in.
>
> Right now I dedicate time for reviewing incoming issues in the core,
> Remoting, "_unsorted", a couple of other modules and a bunch of plugins I
> am supposed to maintain. I can unlikely dedicate more time to review other
> components (would prefer to do bugfixing in core/remoting), but at least I
> am ready to keep working on the current stuff.
>
> BR, Oleg
>
> 2017-04-11 10:07 GMT+02:00 Daniel Beck :
>
>
> > On 10.04.2017, at 22:44, Slide  wrote:
> >
> > if you are interested!
>
> I am.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/XToix3QpL_k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/2F5B15D7-B147-4F4B-B8CE-04760B1F9A7D%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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAypc6o5YBYDAVNKqD0euqGhLJ%2B-Z929s8fkZU51ZZv%2BA%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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHqHF8aboPTWkGQYx%2BF_qCHPd2bMGZ8HChVauPuk6NbGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug Triage "Team"

[Oleg Nenashev]

Hi all,

I am in.

Right now I dedicate time for reviewing incoming issues in the core,
Remoting, "_unsorted", a couple of other modules and a bunch of plugins I
am supposed to maintain. I can unlikely dedicate more time to review other
components (would prefer to do bugfixing in core/remoting), but at least I
am ready to keep working on the current stuff.

BR, Oleg

2017-04-11 10:07 GMT+02:00 Daniel Beck :

>
> > On 10.04.2017, at 22:44, Slide  wrote:
> >
> > if you are interested!
>
> I am.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/jenkinsci-dev/XToix3QpL_k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/2F5B15D7-B147-4F4B-B8CE-04760B1F9A7D%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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAypc6o5YBYDAVNKqD0euqGhLJ%2B-Z929s8fkZU51ZZv%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug Triage "Team"

[Daniel Beck]

> On 10.04.2017, at 22:44, Slide  wrote:
> 
> if you are interested!

I am.

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/2F5B15D7-B147-4F4B-B8CE-04760B1F9A7D%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Bug Triage "Team"

[Mark Waite]

I'm interested.  Please include me.

Mark Waite

On Mon, Apr 10, 2017 at 2:57 PM Richard Bywater  wrote:

> Not sure how much time I'll be able to dedicate but interested in keeping
> getting up-to-date about this effort.
>
> Richard.
>
> On Tue, 11 Apr 2017 at 08:44 Slide  wrote:
>
> I wanted to follow up on this now that all the craziness of the start of
> the year (new babies and adoptions in my family!) are done. There were a
> few people who responded to me about being interested in helping with this
> Bug Triage. If you are still interested, please let me know. I setg up a
> filter on JIRA [1] for people to work from, with the idea being we would
> look at issues in core and the wizard suggested plugins as an initial go.
> There are also several hundred issues with no component at all [2] that
> could use a look as well. If anyone is interested in adding their plugin to
> the triage, please let me know and I will update the filter and send it
> out. I'd like to start the team looking at issues at the start of May. As a
> review, we would like to do the following:
>
> 1) Assign correct components to issues
> 2) Replicate issues as possible and update with findings to help issue
> owners recreate the issue (PR's with new tests would be great in this
> regard)
> 3) Do NOT set assignee on issues because of the workflow that people use
> 4) Close out issues as "Incomplete" if they are old and have few details
> to try and reproduce them
>
> Please let me know if I am missing anything and if you are interested!
>
> Regards,
>
> Alex
>
> 1 -
> https://issues.jenkins-ci.org/browse/JENKINS-22?jql=project%20%3D%20JENKINS%20AND%20(resolved%20is%20EMPTY%20OR%20resolution%20%3D%20Unresolved)%20AND%20component%20in%20(core%2C%20cloudbees-folder-plugin%2C%20antisamy-markup-formatter-plugin%2C%20build-timeout-plugin%2C%20timestamper-plugin%2C%20ws-cleanup-plugin%2C%20ant-plugin%2C%20gradle-plugin%2C%20workflow-aggregator-plugin%2C%20github-organization-folder-plugin%2C%20pipeline-stage-view-plugin%2C%20git-plugin%2C%20subversion-plugin%2C%20ssh-slaves-plugin%2C%20matrix-auth-plugin%2C%20pam-auth-plugin%2C%20ldap-plugin%2C%20email-ext-plugin%2C%20email-ext-plugin%2C%20mailer-plugin)%20ORDER%20BY%20key
>
> 2 -
> https://issues.jenkins-ci.org/browse/JENKINS-11545?jql=project%20%3D%20JENKINS%20AND%20component%20is%20EMPTY%20
>
> On Mon, Jan 30, 2017 at 12:45 PM Oleg Nenashev 
> wrote:
>
> Hi,
>
> Just FYI, at some point we have created the _unsorted
> component
> in JIRA. It is being shown as the first one in the component selection
> list, so some issues go into this component. Mostly there are barely
> created issues, unfortunately. Of course such component does not prevent
> people from randomly setting components like they do now sometimes.
>
> Generally I agree with the summary above. The project will definitely
> benefit from any kind of a triaging team IFF we find people, who are ready
> to consistently dedicate time to it
>
> вторник, 24 января 2017 г., 23:33:21 UTC+1 пользователь slide написал:
>
> Sure, that shouldn't be a problem
>
> On Tue, Jan 24, 2017 at 3:07 PM Ullrich Hafner 
> wrote:
>
> Am 23.01.2017 um 22:47 schrieb Slide :
>
> Ok, to summarize...
>
> 1) We don't want to set the assignee
> 2) We do want to make sure the component(s) are correct
> 3) We want to try and replicate the issue and add findings
> 4) We want to close out issues that are very old with little information
> to clean things up
>
> Is there anything I missed?
>
>
> Would it be possible to label issues in step 3 that are important and not
> overly complex to reproduce? I’m planning to assign several student
> projects to create acceptance tests for the ATH in the upcoming summer
> semester. The last time we tried to do this was not very effective since it
> took a long time to find good issues that could be transformed to an
> acceptance test.
>
> Thanks for the discussion on this!
>
> Alex
>
> On Mon, Jan 23, 2017 at 2:37 PM Ullrich Hafner 
> wrote:
>
> 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 :
>
>
> >
> >
> >> On 21.01.2017, at 15:07, Baptiste Mathus  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 

Re: Bug Triage "Team"

[Richard Bywater]

Not sure how much time I'll be able to dedicate but interested in keeping
getting up-to-date about this effort.

Richard.

On Tue, 11 Apr 2017 at 08:44 Slide  wrote:

> I wanted to follow up on this now that all the craziness of the start of
> the year (new babies and adoptions in my family!) are done. There were a
> few people who responded to me about being interested in helping with this
> Bug Triage. If you are still interested, please let me know. I setg up a
> filter on JIRA [1] for people to work from, with the idea being we would
> look at issues in core and the wizard suggested plugins as an initial go.
> There are also several hundred issues with no component at all [2] that
> could use a look as well. If anyone is interested in adding their plugin to
> the triage, please let me know and I will update the filter and send it
> out. I'd like to start the team looking at issues at the start of May. As a
> review, we would like to do the following:
>
> 1) Assign correct components to issues
> 2) Replicate issues as possible and update with findings to help issue
> owners recreate the issue (PR's with new tests would be great in this
> regard)
> 3) Do NOT set assignee on issues because of the workflow that people use
> 4) Close out issues as "Incomplete" if they are old and have few details
> to try and reproduce them
>
> Please let me know if I am missing anything and if you are interested!
>
> Regards,
>
> Alex
>
> 1 -
> https://issues.jenkins-ci.org/browse/JENKINS-22?jql=project%20%3D%20JENKINS%20AND%20(resolved%20is%20EMPTY%20OR%20resolution%20%3D%20Unresolved)%20AND%20component%20in%20(core%2C%20cloudbees-folder-plugin%2C%20antisamy-markup-formatter-plugin%2C%20build-timeout-plugin%2C%20timestamper-plugin%2C%20ws-cleanup-plugin%2C%20ant-plugin%2C%20gradle-plugin%2C%20workflow-aggregator-plugin%2C%20github-organization-folder-plugin%2C%20pipeline-stage-view-plugin%2C%20git-plugin%2C%20subversion-plugin%2C%20ssh-slaves-plugin%2C%20matrix-auth-plugin%2C%20pam-auth-plugin%2C%20ldap-plugin%2C%20email-ext-plugin%2C%20email-ext-plugin%2C%20mailer-plugin)%20ORDER%20BY%20key
>
> 2 -
> https://issues.jenkins-ci.org/browse/JENKINS-11545?jql=project%20%3D%20JENKINS%20AND%20component%20is%20EMPTY%20
>
> On Mon, Jan 30, 2017 at 12:45 PM Oleg Nenashev 
> wrote:
>
> Hi,
>
> Just FYI, at some point we have created the _unsorted
> component
> in JIRA. It is being shown as the first one in the component selection
> list, so some issues go into this component. Mostly there are barely
> created issues, unfortunately. Of course such component does not prevent
> people from randomly setting components like they do now sometimes.
>
> Generally I agree with the summary above. The project will definitely
> benefit from any kind of a triaging team IFF we find people, who are ready
> to consistently dedicate time to it
>
> вторник, 24 января 2017 г., 23:33:21 UTC+1 пользователь slide написал:
>
> Sure, that shouldn't be a problem
>
> On Tue, Jan 24, 2017 at 3:07 PM Ullrich Hafner 
> wrote:
>
> Am 23.01.2017 um 22:47 schrieb Slide :
>
> Ok, to summarize...
>
> 1) We don't want to set the assignee
> 2) We do want to make sure the component(s) are correct
> 3) We want to try and replicate the issue and add findings
> 4) We want to close out issues that are very old with little information
> to clean things up
>
> Is there anything I missed?
>
>
> Would it be possible to label issues in step 3 that are important and not
> overly complex to reproduce? I’m planning to assign several student
> projects to create acceptance tests for the ATH in the upcoming summer
> semester. The last time we tried to do this was not very effective since it
> took a long time to find good issues that could be transformed to an
> acceptance test.
>
> Thanks for the discussion on this!
>
> Alex
>
> On Mon, Jan 23, 2017 at 2:37 PM Ullrich Hafner 
> wrote:
>
> 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 :
>
>
> >
> >
> >> On 21.01.2017, at 15:07, Baptiste Mathus  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 

Re: Bug Triage "Team"

[Slide]

I wanted to follow up on this now that all the craziness of the start of
the year (new babies and adoptions in my family!) are done. There were a
few people who responded to me about being interested in helping with this
Bug Triage. If you are still interested, please let me know. I setg up a
filter on JIRA [1] for people to work from, with the idea being we would
look at issues in core and the wizard suggested plugins as an initial go.
There are also several hundred issues with no component at all [2] that
could use a look as well. If anyone is interested in adding their plugin to
the triage, please let me know and I will update the filter and send it
out. I'd like to start the team looking at issues at the start of May. As a
review, we would like to do the following:

1) Assign correct components to issues
2) Replicate issues as possible and update with findings to help issue
owners recreate the issue (PR's with new tests would be great in this
regard)
3) Do NOT set assignee on issues because of the workflow that people use
4) Close out issues as "Incomplete" if they are old and have few details to
try and reproduce them

Please let me know if I am missing anything and if you are interested!

Regards,

Alex

1 -
https://issues.jenkins-ci.org/browse/JENKINS-22?jql=project%20%3D%20JENKINS%20AND%20(resolved%20is%20EMPTY%20OR%20resolution%20%3D%20Unresolved)%20AND%20component%20in%20(core%2C%20cloudbees-folder-plugin%2C%20antisamy-markup-formatter-plugin%2C%20build-timeout-plugin%2C%20timestamper-plugin%2C%20ws-cleanup-plugin%2C%20ant-plugin%2C%20gradle-plugin%2C%20workflow-aggregator-plugin%2C%20github-organization-folder-plugin%2C%20pipeline-stage-view-plugin%2C%20git-plugin%2C%20subversion-plugin%2C%20ssh-slaves-plugin%2C%20matrix-auth-plugin%2C%20pam-auth-plugin%2C%20ldap-plugin%2C%20email-ext-plugin%2C%20email-ext-plugin%2C%20mailer-plugin)%20ORDER%20BY%20key

2 -
https://issues.jenkins-ci.org/browse/JENKINS-11545?jql=project%20%3D%20JENKINS%20AND%20component%20is%20EMPTY%20

On Mon, Jan 30, 2017 at 12:45 PM Oleg Nenashev 
wrote:

> Hi,
>
> Just FYI, at some point we have created the _unsorted
> component
> in JIRA. It is being shown as the first one in the component selection
> list, so some issues go into this component. Mostly there are barely
> created issues, unfortunately. Of course such component does not prevent
> people from randomly setting components like they do now sometimes.
>
> Generally I agree with the summary above. The project will definitely
> benefit from any kind of a triaging team IFF we find people, who are ready
> to consistently dedicate time to it
>
> вторник, 24 января 2017 г., 23:33:21 UTC+1 пользователь slide написал:
>
> Sure, that shouldn't be a problem
>
> On Tue, Jan 24, 2017 at 3:07 PM Ullrich Hafner 
> wrote:
>
> Am 23.01.2017 um 22:47 schrieb Slide :
>
> Ok, to summarize...
>
> 1) We don't want to set the assignee
> 2) We do want to make sure the component(s) are correct
> 3) We want to try and replicate the issue and add findings
> 4) We want to close out issues that are very old with little information
> to clean things up
>
> Is there anything I missed?
>
>
> Would it be possible to label issues in step 3 that are important and not
> overly complex to reproduce? I’m planning to assign several student
> projects to create acceptance tests for the ATH in the upcoming summer
> semester. The last time we tried to do this was not very effective since it
> took a long time to find good issues that could be transformed to an
> acceptance test.
>
> Thanks for the discussion on this!
>
> Alex
>
> On Mon, Jan 23, 2017 at 2:37 PM Ullrich Hafner 
> wrote:
>
> 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 :
>
>
> >
> >
> >> On 21.01.2017, at 15:07, Baptiste Mathus  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 jenkinsci-de...@googlegroups.com.
>
>
> > 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 

Re: Bug Triage "Team"

[Oleg Nenashev]

Hi, 

Just FYI, at some point we have created the _unsorted 
component
 
in JIRA. It is being shown as the first one in the component selection 
list, so some issues go into this component. Mostly there are barely 
created issues, unfortunately. Of course such component does not prevent 
people from randomly setting components like they do now sometimes.

Generally I agree with the summary above. The project will definitely 
benefit from any kind of a triaging team IFF we find people, who are ready 
to consistently dedicate time to it

вторник, 24 января 2017 г., 23:33:21 UTC+1 пользователь slide написал:
>
> Sure, that shouldn't be a problem
>
> On Tue, Jan 24, 2017 at 3:07 PM Ullrich Hafner  > wrote:
>
>> Am 23.01.2017 um 22:47 schrieb Slide :
>>
>> Ok, to summarize...
>>
>> 1) We don't want to set the assignee
>> 2) We do want to make sure the component(s) are correct
>> 3) We want to try and replicate the issue and add findings
>> 4) We want to close out issues that are very old with little information 
>> to clean things up
>>
>> Is there anything I missed?
>>
>>
>> Would it be possible to label issues in step 3 that are important and not 
>> overly complex to reproduce? I’m planning to assign several student 
>> projects to create acceptance tests for the ATH in the upcoming summer 
>> semester. The last time we tried to do this was not very effective since it 
>> took a long time to find good issues that could be transformed to an 
>> acceptance test.  
>>
>> Thanks for the discussion on this!
>>
>> Alex
>>
>> On Mon, Jan 23, 2017 at 2:37 PM Ullrich Hafner > > wrote:
>>
>>> 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 >> >:
>>> >
>>> >
>>> >> On 21.01.2017, at 15:07, Baptiste Mathus >> > 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 jenkinsci-de...@googlegroups.com .
>>> > 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 jenkinsci-de...@googlegroups.com .
>>> 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.
>>>
>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com .
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVdm8BYO2Cwnpq_k_AJB5VeQY%3Dc5ZV9ceBmFv%2BALX8-9Kw%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 jenkinsci-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/D65B16DD-EFEC-47F1-BC9B-4893379BEDC4%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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this 

Re: Bug Triage "Team"

[Slide]

Sure, that shouldn't be a problem

On Tue, Jan 24, 2017 at 3:07 PM Ullrich Hafner 
wrote:

> Am 23.01.2017 um 22:47 schrieb Slide :
>
> Ok, to summarize...
>
> 1) We don't want to set the assignee
> 2) We do want to make sure the component(s) are correct
> 3) We want to try and replicate the issue and add findings
> 4) We want to close out issues that are very old with little information
> to clean things up
>
> Is there anything I missed?
>
>
> Would it be possible to label issues in step 3 that are important and not
> overly complex to reproduce? I’m planning to assign several student
> projects to create acceptance tests for the ATH in the upcoming summer
> semester. The last time we tried to do this was not very effective since it
> took a long time to find good issues that could be transformed to an
> acceptance test.
>
> Thanks for the discussion on this!
>
> Alex
>
> On Mon, Jan 23, 2017 at 2:37 PM Ullrich Hafner 
> wrote:
>
> 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 :
> >
> >
> >> On 21.01.2017, at 15:07, Baptiste Mathus  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 jenkinsci-dev+unsubscr...@googlegroups.com.
> > 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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.
>
>
> --
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVdm8BYO2Cwnpq_k_AJB5VeQY%3Dc5ZV9ceBmFv%2BALX8-9Kw%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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/D65B16DD-EFEC-47F1-BC9B-4893379BEDC4%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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVd%3D-e7odRe1kbxNdPEt5XH4%2BKzg7nipB3f9Q9cPtYYtng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug Triage "Team"

[Ullrich Hafner]

> Am 23.01.2017 um 22:47 schrieb Slide :
> 
> Ok, to summarize...
> 
> 1) We don't want to set the assignee
> 2) We do want to make sure the component(s) are correct
> 3) We want to try and replicate the issue and add findings
> 4) We want to close out issues that are very old with little information to 
> clean things up
> 
> Is there anything I missed?
> 

Would it be possible to label issues in step 3 that are important and not 
overly complex to reproduce? I’m planning to assign several student projects to 
create acceptance tests for the ATH in the upcoming summer semester. The last 
time we tried to do this was not very effective since it took a long time to 
find good issues that could be transformed to an acceptance test.  

> Thanks for the discussion on this!
> 
> Alex
> 
> On Mon, Jan 23, 2017 at 2:37 PM Ullrich Hafner  > wrote:
> 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  > >:
> >
> >
> >> On 21.01.2017, at 15:07, Baptiste Mathus  >> > 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 jenkinsci-dev+unsubscr...@googlegroups.com 
> > .
> > 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 jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> 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 
> .
> 
> -- 
> 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 jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVdm8BYO2Cwnpq_k_AJB5VeQY%3Dc5ZV9ceBmFv%2BALX8-9Kw%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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/D65B16DD-EFEC-47F1-BC9B-4893379BEDC4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug Triage "Team"

[Ullrich Hafner]

> Am 24.01.2017 um 09:10 schrieb Baptiste Mathus :
> 
> 
> 2017-01-24 1:11 GMT+01:00 Mark Waite  >:
> 
> 
> On Mon, Jan 23, 2017 at 3:06 PM Ullrich Hafner  > wrote:
>> Am 21.01.2017 um 15:07 schrieb 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,
> 
> 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.
> 

>From a developers (or open source enthusiast) view that makes totally sense to 
>me. However, I’m just not sure if users who are not interested in 
>participating in Jenkins development think also this way. Maybe it would help 
>to document our new bug triage process in the wiki or web page.

>  
> 
> 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?
Different teams use different approaches so there is no standard way. The 
assignee typically changes during the life cycle of a bug (Jira’s default is 
that you must have an assignee for an issue. You can remove this restriction in 
the project configuration). Most (business) projects I worked on use an 
approach similar to the following one: In the beginning typically a triage team 
(or project lead) is the owner (assignee) of the bugs. They clarify the issue 
description and check if the issues are valid. After the bugs are prioritized 
they are assigned to releases of a product. Bugs that never go into a release 
are typically closed as won’t fix (or a similar better sounding resolution). 
(Some projects marked these bugs open with no assignee. This works in the 
beginning, but after you have a certain amount of issues you loose the control 
about which bugs to select for the next release). If a bug is planned for a 
release it is assigned to a developer. Here the developer marks the issue as 
„In Progress“. After the issue has been fixed the developer marks it as 
resolved and assigns this issue to another person who is going to verify the 
fix (the next stage in a pipeline). If testing finds no problems than the bug 
will be closed. Here the assignee should be set to the original developer 
again. 

This full fledged approach makes no sense for the many one-developer teams who 
are responsible for a Jenkins plugin. Here the assignee most likely will never 
change. I think the best approach would be that all plugins (i.e. components in 
Jira) that have a component lead set should use it as default assignee. All 
teams who prefer the no-assignee solution should simply remove the component 
lead setting.   

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

Re: Bug Triage "Team"

[Mark Waite]

On Mon, Jan 23, 2017 at 3:06 PM Ullrich Hafner 
wrote:

> Am 21.01.2017 um 15:07 schrieb 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,
>
>
> 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.

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.

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 :
>
> 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 

Re: Bug Triage "Team"

[Ullrich Hafner]

> Am 21.01.2017 um 15:07 schrieb 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,

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  >:
> 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 
>> >:
>> 
>> 
>> 
>> On 20 January 2017 at 10:29, Ullrich Hafner > > wrote:
>> 
>>> Am 20.01.2017 um 08:16 schrieb Stephen Connolly 
>>> >:
>>> 
>>> 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 

Re: Bug Triage "Team"

[Slide]

Ok, to summarize...

1) We don't want to set the assignee
2) We do want to make sure the component(s) are correct
3) We want to try and replicate the issue and add findings
4) We want to close out issues that are very old with little information to
clean things up

Is there anything I missed?

Thanks for the discussion on this!

Alex

On Mon, Jan 23, 2017 at 2:37 PM Ullrich Hafner 
wrote:

> 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 :
> >
> >
> >> On 21.01.2017, at 15:07, Baptiste Mathus  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 jenkinsci-dev+unsubscr...@googlegroups.com.
> > 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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.
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVdm8BYO2Cwnpq_k_AJB5VeQY%3Dc5ZV9ceBmFv%2BALX8-9Kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug Triage "Team"

[Ullrich 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 :
> 
> 
>> On 21.01.2017, at 15:07, Baptiste Mathus  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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
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.

Re: Bug Triage "Team"

[Daniel Beck]

> On 21.01.2017, at 15:07, Baptiste Mathus  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 jenkinsci-dev+unsubscr...@googlegroups.com.
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.

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 :

> 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 <
> stephen.alan.conno...@gmail.com>:
>
>
>
> On 20 January 2017 at 10:29, Ullrich Hafner 
> wrote:
>
>>
>> Am 20.01.2017 um 08:16 schrieb Stephen Connolly <
>> stephen.alan.conno...@gmail.com>:
>>
>> 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)
>> 

Re: Bug Triage "Team"

[Ullrich 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 
> :
> 
> 
> 
> On 20 January 2017 at 10:29, Ullrich Hafner  > wrote:
> 
>> Am 20.01.2017 um 08:16 schrieb Stephen Connolly 
>> >:
>> 
>> 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 > > wrote:
>> On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner > > 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 

Re: Bug Triage "Team"

[Stephen Connolly]

On 20 January 2017 at 10:29, Ullrich Hafner 
wrote:

>
> Am 20.01.2017 um 08:16 schrieb Stephen Connolly <
> stephen.alan.conno...@gmail.com>:
>
> 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  wrote:
>
>> On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner 
>> 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 :
>>
>> 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 
>> wrote:
>>
>> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick 
>> wrote:
>>
>> On Thu, Jan 19, 2017 at 12:34 PM, Slide  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

Re: Bug Triage "Team"

[Arnaud Héritier]

On Fri, Jan 20, 2017 at 11:29 AM, Ullrich Hafner 
wrote:

>
> Am 20.01.2017 um 08:16 schrieb Stephen Connolly <
> stephen.alan.conno...@gmail.com>:
>
> 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  wrote:
>
>> On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner 
>> 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 :
>>
>> If that is a common practice, then we can skip setting the assignee 

Re: Bug Triage "Team"

[Stephen Connolly]

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 <
stephen.alan.conno...@gmail.com> wrote:

> On 20 January 2017 at 10:29, Ullrich Hafner 
> wrote:
>
>>
>> Am 20.01.2017 um 08:16 schrieb Stephen Connolly <
>> stephen.alan.conno...@gmail.com>:
>>
>> 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 
>> wrote:
>>
>>> On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner 
>>> 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 

Re: Bug Triage "Team"

[Stephen Connolly]

On 20 January 2017 at 10:29, Ullrich Hafner 
wrote:

>
> Am 20.01.2017 um 08:16 schrieb Stephen Connolly <
> stephen.alan.conno...@gmail.com>:
>
> 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  wrote:
>
>> On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner 
>> 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 :
>>
>> 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 

Re: Bug Triage "Team"

[Ullrich Hafner]

> Am 20.01.2017 um 08:16 schrieb Stephen Connolly 
> :
> 
> 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  > wrote:
> On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner  > 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 > >:
>> 
>> 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 > > wrote:
>> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick > > wrote:
>> On Thu, Jan 19, 2017 at 12:34 PM, Slide > > 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 

Re: Bug Triage "Team"

[Ullrich Hafner]

> Am 20.01.2017 um 01:21 schrieb Mark Waite :
> 
> 
> 
> On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner  > 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 > >:
>> 
>> 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 > > wrote:
>> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick > > wrote:
>> On Thu, Jan 19, 2017 at 12:34 PM, Slide > > 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 jenkinsci-dev+unsubscr...@googlegroups.com 
>> .
>> 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 
>> 

Re: Bug Triage "Team"

[Stephen Connolly]

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  wrote:

> On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner 
> 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 :
>
> 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 
> wrote:
>
> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick  wrote:
>
> On Thu, Jan 19, 2017 at 12:34 PM, Slide  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 jenkinsci-dev+unsubscr...@googlegroups.com.
>
>
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com
> 

Re: Bug Triage "Team"

[Mark Waite]

On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner 
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 :
>
> 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 
> wrote:
>
> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick  wrote:
>
> On Thu, Jan 19, 2017 at 12:34 PM, Slide  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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 

Re: Bug Triage "Team"

[Ullrich Hafner]

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 :
> 
> 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  > wrote:
> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick  > wrote:
> On Thu, Jan 19, 2017 at 12:34 PM, Slide  > 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 jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> 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 jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> 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 jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
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.

Re: Bug Triage "Team"

[Baptiste Mathus]

2017-01-19 21:31 GMT+01:00 Mark Waite :

>
>
> On Thu, Jan 19, 2017 at 12:51 PM Slide  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 
>> wrote:
>>
>> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick 
>> wrote:
>>
>> On Thu, Jan 19, 2017 at 12:34 PM, Slide  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 jenkinsci-dev+unsubscr...@googlegroups.com.
>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>>
>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 

Re: Bug Triage "Team"

[Mark Waite]

On Thu, Jan 19, 2017 at 12:51 PM Slide  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 
> wrote:
>
> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick  wrote:
>
> On Thu, Jan 19, 2017 at 12:34 PM, Slide  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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
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.

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 
wrote:

> On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick  wrote:
>
> On Thu, Jan 19, 2017 at 12:34 PM, Slide  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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
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.

Re: Bug Triage "Team"

[Jesse Glick]

On Thu, Jan 19, 2017 at 12:34 PM, Slide  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 jenkinsci-dev+unsubscr...@googlegroups.com.
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.

Re: Bug Triage "Team"

[Owen Mehegan]

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" <slide.o@gmail.com> 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
>
>
> 1 - http://meetings.jenkins-ci.org/jenkins-meeting/2017/
> jenkins-meeting.2017-01-18-18.01.html
> 2 - https://issues.jenkins-ci.org
>
> --
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CAPiUgVfuKH8SyZdg_MPDi963hLy-
> HAAjfWS8HSYw3zdHLk7FNw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfuKH8SyZdg_MPDi963hLy-HAAjfWS8HSYw3zdHLk7FNw%40mail.gmail.com?utm_medium=email_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 jenkinsci-dev+unsubscr...@googlegroups.com.
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.

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


1 -
http://meetings.jenkins-ci.org/jenkins-meeting/2017/jenkins-meeting.2017-01-18-18.01.html
2 - https://issues.jenkins-ci.org

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
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.