Bug Triage "Team"

103 views
Skip to first unread message

Slide

unread,
Jan 19, 2017, 12:34:51 PM1/19/17
to Jenkins Developer List
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



Owen Mehegan

unread,
Jan 19, 2017, 12:40:57 PM1/19/17
to jenkin...@googlegroups.com

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!

--
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+unsubscribe@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.

Jesse Glick

unread,
Jan 19, 2017, 2:11:14 PM1/19/17
to Jenkins Dev
On Thu, Jan 19, 2017 at 12:34 PM, Slide <slide...@gmail.com> 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.

Mark Waite

unread,
Jan 19, 2017, 2:48:36 PM1/19/17
to jenkin...@googlegroups.com
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-de...@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.

Slide

unread,
Jan 19, 2017, 2:51:15 PM1/19/17
to jenkin...@googlegroups.com
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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH_W8iHnQUL_xjV2fA-pCibkzfOkkU2P%2BzUNrdqV0H43w%40mail.gmail.com.

Mark Waite

unread,
Jan 19, 2017, 3:31:47 PM1/19/17
to jenkin...@googlegroups.com
On Thu, Jan 19, 2017 at 12:51 PM Slide <slide...@gmail.com> 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
 

Baptiste Mathus

unread,
Jan 19, 2017, 3:55:21 PM1/19/17
to Jenkins Developers
2017-01-19 21:31 GMT+01:00 Mark Waite <mark.ea...@gmail.com>:


On Thu, Jan 19, 2017 at 12:51 PM Slide <slide...@gmail.com> 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 <mark.ea...@gmail.com> wrote:
On Thu, Jan 19, 2017 at 12:11 PM Jesse Glick <jgl...@cloudbees.com> wrote:
On Thu, Jan 19, 2017 at 12:34 PM, Slide <slide...@gmail.com> 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+unsubscribe@googlegroups.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+unsubscribe@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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFXoCOozn%2B2bBce03X5DZbyNPA%3DucnAEjrKkzcpRSx4pQ%40mail.gmail.com.

Ullrich Hafner

unread,
Jan 19, 2017, 3:59:45 PM1/19/17
to Jenkins Developers
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.) 


Mark Waite

unread,
Jan 19, 2017, 7:21:48 PM1/19/17
to jenkin...@googlegroups.com
On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <ullrich...@gmail.com> 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
 

Stephen Connolly

unread,
Jan 20, 2017, 2:17:12 AM1/20/17
to jenkin...@googlegroups.com
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)



For more options, visit https://groups.google.com/d/optout.


--
Sent from my phone

Ullrich Hafner

unread,
Jan 20, 2017, 4:49:00 AM1/20/17
to Jenkins Developers
Am 20.01.2017 um 01:21 schrieb Mark Waite <mark.ea...@gmail.com>:



On Thu, Jan 19, 2017 at 1:59 PM Ullrich Hafner <ullrich...@gmail.com> 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. 

Ullrich Hafner

unread,
Jan 20, 2017, 5:29:17 AM1/20/17
to Jenkins Developers
Am 20.01.2017 um 08:16 schrieb Stephen Connolly <stephen.al...@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

Stephen Connolly

unread,
Jan 20, 2017, 6:03:16 AM1/20/17
to jenkin...@googlegroups.com
On 20 January 2017 at 10:29, Ullrich Hafner <ullrich...@gmail.com> wrote:


Am 20.01.2017 um 08:16 schrieb Stephen Connolly <stephen.alan.connolly@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)

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.com.
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.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+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com.

Stephen Connolly

unread,
Jan 20, 2017, 6:10:31 AM1/20/17
to jenkin...@googlegroups.com
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).

Arnaud Héritier

unread,
Jan 20, 2017, 7:15:40 AM1/20/17
to jenkin...@googlegroups.com


On Fri, Jan 20, 2017 at 11:29 AM, Ullrich Hafner <ullrich...@gmail.com> wrote:


Am 20.01.2017 um 08:16 schrieb Stephen Connolly <stephen.alan.connolly@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)
 


To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.com.
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
-----
Arnaud Héritier
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Stephen Connolly

unread,
Jan 20, 2017, 8:39:39 AM1/20/17
to jenkin...@googlegroups.com
On 20 January 2017 at 10:29, Ullrich Hafner <ullrich...@gmail.com> wrote:

Am 20.01.2017 um 08:16 schrieb Stephen Connolly <stephen.alan.connolly@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  

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.com.
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.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+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78782FEB-70BD-4396-AE7D-7951877B4765%40gmail.com.

Ullrich Hafner

unread,
Jan 20, 2017, 6:32:14 PM1/20/17
to Jenkins Developers
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). 

 

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/CA%2BnPnMw0OH2Wb9gz-dRVNTFX%2BUh5Oa7gpZrC%2B7Xd15W0u6cfvg%40mail.gmail.com.

Baptiste Mathus

unread,
Jan 21, 2017, 9:08:09 AM1/21/17
to Jenkins Developers
+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 <ullrich...@gmail.com>:
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.connolly@gmail.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56A2B757-0333-4BD0-B5BF-B07BA0DB16A4%40gmail.com.

Daniel Beck

unread,
Jan 21, 2017, 5:18:30 PM1/21/17
to jenkin...@googlegroups.com

> On 21.01.2017, at 15:07, Baptiste Mathus <m...@batmat.net> 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?

Ullrich Hafner

unread,
Jan 23, 2017, 4:37:16 PM1/23/17
to Jenkins Developers
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.
> --
> 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.

Slide

unread,
Jan 23, 2017, 4:48:07 PM1/23/17
to Jenkins Developers
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

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8C8FA5DF-8CEA-4F3C-8599-F76C9C53BD22%40gmail.com.

Ullrich Hafner

unread,
Jan 23, 2017, 5:06:44 PM1/23/17
to Jenkins Developers
Am 21.01.2017 um 15:07 schrieb Baptiste Mathus <m...@batmat.net>:

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

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/CANWgJS6SETyf1-Jit0vny_pv0KsNtpt%3DijtOBqoNG2E6isUDWA%40mail.gmail.com.

Mark Waite

unread,
Jan 23, 2017, 7:12:14 PM1/23/17
to jenkin...@googlegroups.com
On Mon, Jan 23, 2017 at 3:06 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
Am 21.01.2017 um 15:07 schrieb Baptiste Mathus <m...@batmat.net>:

+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 <ullrich...@gmail.com>:
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.al...@gmail.com>:



On 20 January 2017 at 10:29, Ullrich Hafner <ullrich...@gmail.com> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.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-de...@googlegroups.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-de...@googlegroups.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-de...@googlegroups.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-de...@googlegroups.com.
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.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-de...@googlegroups.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-de...@googlegroups.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-de...@googlegroups.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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6SETyf1-Jit0vny_pv0KsNtpt%3DijtOBqoNG2E6isUDWA%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.

Baptiste Mathus

unread,
Jan 24, 2017, 3:10:43 AM1/24/17
to Jenkins Developers
2017-01-24 1:11 GMT+01:00 Mark Waite <mark.ea...@gmail.com>:


On Mon, Jan 23, 2017 at 3:06 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
Am 21.01.2017 um 15:07 schrieb Baptiste Mathus <m...@batmat.net>:

+1 for no assignee by default and adding the NEW status
Having a state to basically say: "this is issue is new, but has not been reviewed, so may be invalid/incomplete/whatever for whatever reason" makes sense IMO. And that the Triage team could use for, well, triaging.

Also, I'm trying to think about what the "default assignee" way of working right sends as message. It may push back some ppl willing to contribute,

Why would this push back people? A default assignee (as Atlassian defines it) is a person who is responsible for an issue, i.e. the owner (not identical to the person fixing it).

I mistakenly assumed that "assignee" meant "the person who is working on this bug" or at least "the person who will eventually work on this bug".  When a bug was assigned to someone, I was hesitant to start work on that bug without acknowledgment from the current assignee that they are not actively working on the bug.  If the bug is unassigned, then I am more confident that no one is actively working on that bug.

+1. I said that not only out of thin air, but because this is how I started. And seeing an assignee adds a step of commenting on the issue, if I ever dared, then waiting for the answer to take over it. Possibly granted, I would work on it still if blocking, but wouldn't assign it to myself directly generally.

 

I think I can get the same information from reports if I can trust that people use the state "In Progress" to indicate they are actively working on a bug.  I'm happy to start using "In Progress" as well.  There are currently 574 bugs "In Progress", with approximately 10% of them updated in the last month.  Based on that, "In Progress" does not seem to be a widely used status value.

Can you provide a pointer to that Atlassian definition of "assignee"?  I'd like to understand their intended use model.

Likewise, can you further expand on your definition of "responsible for an issue"? 

Is "responsible for an issue"
  • the lead maintainer of the component?
  • the person implementing the fix?
  • the person verifying the fix?
  • the person checking the bug can be duplicated?
  • the person automating tests of the bug?

or "send" the wrong message with essentially newcomers (which are probably the majority) thinking basically when seeing an assignee "cool, someone is looking into that" which is generally (90% of the time?) wrong.

I think the opposite message is also wrong: ohh, no assignee, that means nobody cares about my bug report:-( I think the majority of users reporting a bug is not interested in fixing it on their own. 
(And a side note: as a user of a professional software system (especially one that is used to improve the quality of software) I would expect that most of the issues are going to be solved by the team, not only 10%. But this would be a topic for another discussion: how can we close the gap between new and resolved issues...)


I disagree that "most of the issues are going to be solved by the team", unless you and I have radically different definitions of "team".  I define "team" as "active maintainers of that plugin", which makes the number of people quite small.  I hope that many, many issues are investigated and resolved by a wide collection of infrequent contributors who discover and fix something important to them.

Agree with Mark. I was going to answer I disagree too on opensource, clearly: I am not committed to fix *any* thing that might arise on the opensource plugins I maintain.

And then, anyway, thinking on the professional side, I would say this is actually the same: which company fixes *everything*, even when full time? Actual bugs with high severity, sure, but all that long trail on non blocking "issues" (not even bugs, often) have a very low chance to get worked on any day. And this is fine, because this is also a matter of product management. But I'm drifting here.
 

Mark Waite

I love the idea of the TRIAGE team, thanks a lot Slide for that. I will try to help a bit (though I should already start by being back to more activity on the HOSTING project front).
2017-01-21 0:32 GMT+01:00 Ullrich Hafner <ullrich...@gmail.com>:
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.connolly@gmail.com>:



On 20 January 2017 at 10:29, Ullrich Hafner <ullrich.hafner@gmail.com> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.com.
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFKis8eO0YH0a4TH%2Bp%3DMWmVESAkcpbqeag_LjF3AXBXQg%40mail.gmail.com.

Ullrich Hafner

unread,
Jan 24, 2017, 4:50:32 PM1/24/17
to Jenkins Developers
Am 24.01.2017 um 09:10 schrieb Baptiste Mathus <m...@batmat.net>:


2017-01-24 1:11 GMT+01:00 Mark Waite <mark.ea...@gmail.com>:


On Mon, Jan 23, 2017 at 3:06 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
Am 21.01.2017 um 15:07 schrieb Baptiste Mathus <m...@batmat.net>:

+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 assignee, that means nobody cares about my bug report:-( I think the majority of users reporting a bug is not interested in fixing it on their own. 
(And a side note: as a user of a professional software system (especially one that is used to improve the quality of software) I would expect that most of the issues are going to be solved by the team, not only 10%. But this would be a topic for another discussion: how can we close the gap between new and resolved issues...)


I disagree that "most of the issues are going to be solved by the team", unless you and I have radically different definitions of "team".  I define "team" as "active maintainers of that plugin", which makes the number of people quite small.  I hope that many, many issues are investigated and resolved by a wide collection of infrequent contributors who discover and fix something important to them.

Agree with Mark. I was going to answer I disagree too on opensource, clearly: I am not committed to fix *any* thing that might arise on the opensource plugins I maintain.

Here we have different opinions but that is ok for me, it is our spare time we spend. No project fixes all the bugs but in most projects I’m working on I try too keep a good balance. And I often don’t find spare time to fix a bug but then I add a comment in the issue that here a PR is desired. This works quite well. But this is something one has to sort out for oneself. And we have so many different plugin developers (and teams) that we should not define a standard for all of them. So I would like to be the default assignee for my projects, but if someone does not want this we should make it possible. 
BTW: Having a default assignee for a plugin has another advantage for me as developer: if there is a bug that affects multiple plugins I just assign this bug to the other components default assignee (and ask some questions regarding this issue, etc.) If there is no default assignee then this questions might be send to /dev/null. When I don’t get feedback on the issue I’m not sure if the other component lead just has no time for the fix or did no see the new issue. 

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/CANWgJS5ft%2BN2D6bdg_ai-6L0HFRpsfGCJ0fyPsBKRBOWOLwh0Q%40mail.gmail.com.

Ullrich Hafner

unread,
Jan 24, 2017, 5:07:42 PM1/24/17
to Jenkins Developers
Am 23.01.2017 um 22:47 schrieb Slide <slide...@gmail.com>:

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 <ullrich...@gmail.com> 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 <m...@beckweb.net>:
>
>
>> On 21.01.2017, at 15:07, Baptiste Mathus <m...@batmat.net> 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.

Slide

unread,
Jan 24, 2017, 5:33:21 PM1/24/17
to Jenkins Developers
Sure, that shouldn't be a problem

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D65B16DD-EFEC-47F1-BC9B-4893379BEDC4%40gmail.com.

Oleg Nenashev

unread,
Jan 30, 2017, 2:45:47 PM1/30/17
to Jenkins Developers
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 написал:

Slide

unread,
Apr 10, 2017, 4:44:25 PM4/10/17
to Jenkins Developers
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,


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/aa645daf-82b0-4ac5-a5a9-fec900f4ee18%40googlegroups.com.

Richard Bywater

unread,
Apr 10, 2017, 4:57:25 PM4/10/17
to Jenkins Developers
Not sure how much time I'll be able to dedicate but interested in keeping getting up-to-date about this effort.

Richard.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVd9zMw-3saX7p3_o_auCp4ZC1Ot7dSPsOXXLZsqc4z%2BMw%40mail.gmail.com.

Mark Waite

unread,
Apr 10, 2017, 5:01:37 PM4/10/17
to Jenkins Developers
I'm interested.  Please include me.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMui944h_BRHUQiFzheZdCKidHop9JD8KYsQ7qDKOYXzxpWRiA%40mail.gmail.com.

Daniel Beck

unread,
Apr 11, 2017, 4:07:15 AM4/11/17
to jenkin...@googlegroups.com

> On 10.04.2017, at 22:44, Slide <slide...@gmail.com> wrote:
>
> if you are interested!

I am.

Oleg Nenashev

unread,
Apr 11, 2017, 5:13:17 AM4/11/17
to JenkinsCI Developers
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


--
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+unsubscribe@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.

Mark Waite

unread,
Apr 11, 2017, 7:01:51 AM4/11/17
to JenkinsCI Developers
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 <o.v.ne...@gmail.com> 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 <m...@beckweb.net>:

> On 10.04.2017, at 22:44, Slide <slide...@gmail.com> 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.

Slide

unread,
Apr 11, 2017, 12:49:42 PM4/11/17
to JenkinsCI Developers
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHqHF8aboPTWkGQYx%2BF_qCHPd2bMGZ8HChVauPuk6NbGQ%40mail.gmail.com.

Oleg Nenashev

unread,
Dec 16, 2018, 7:05:08 AM12/16/18
to Jenkins Developers
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
Thanks a lot to everybody who contributes to the issue triage in Jenkins JIRA!

Best regards,
Oleg

Oleg Nenashev

unread,
Jun 16, 2020, 4:22:04 PM6/16/20
to Jenkins Developers
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.
  • 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

Marky Jackson

unread,
Jun 16, 2020, 4:26:13 PM6/16/20
to Oleg Nenashev, Jenkins Developers
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 <o.v.ne...@gmail.com> wrote:
>

Sladyn Nunes

unread,
Jun 16, 2020, 4:29:42 PM6/16/20
to jenkin...@googlegroups.com, Oleg Nenashev
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 <marky.r...@gmail.com> 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 <o.v.ne...@gmail.com> 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-de...@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.

Slide

unread,
Jun 16, 2020, 4:50:10 PM6/16/20
to jenkin...@googlegroups.com, Oleg Nenashev
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.

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

Mark Waite

unread,
Jun 16, 2020, 5:08:11 PM6/16/20
to jenkinsci-dev
I'm interested.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/31c5018d-da6f-4f71-93db-aab3ebcd9aaao%40googlegroups.com.

Vlad Silverman

unread,
Jun 16, 2020, 5:22:30 PM6/16/20
to jenkin...@googlegroups.com
I would be interested

Oleg Nenashev

unread,
Jul 13, 2020, 4:53:54 AM7/13/20
to Jenkins Developers
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 <mark.e...@gmail.com> wrote:

I'm interested.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.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 jenkin...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages