Page 1 of 1

How should a bug tracker be managed?

Posted: Thu Oct 25, 2018 6:32 pm
by ssj71
After much emotional discussion about a particular project, this thread is started to try to discuss pros and cons of particular bug-tracking strategies.

Listed criticisms of some projects trackers mostly centered around not closing old bugs (10+ years old), common explanation being the devs aren't taking the time to maintain their trackers. Reasoning for the criticism is that it makes the project look like it is not supporting users properly (particular to the project was that they use a paid support model, note that the GPL explicitly states that programs don't come with support, yet many developers have a desire to offer it).

So lets have some discussion (without attacking developers) that might actually help devs improve their project management. Feel free to use specific examples, discuss other bug-tracking practices or strategies you like or dislike, the reasoning, and/or explanations for status quo. How to encourage more and better bug reports and patch contributions is of course within scope of the topic.

Re: How should a bug tracker be managed?

Posted: Thu Oct 25, 2018 6:43 pm
by ssj71
Trying to summarise various suggestions about how to avoid "necro-bugs" included:

* creating a single issue containing a list of all old unaddressed issues, closing the latter
* assuming every issue older than X years is a won't-fix and closing it (assuming users will re-open a bug if needed)
* looking through old issues and determining if they still apply, closing or updating appropriately


each of these suggestions takes more time than leaving bugs until they are specifically addressed. The 3rd is probably the best practice but also takes the most time.

Should a non-developer volunteer to contribute bug management I think probably the 3rd would be what to strive for, but if a project is lacking resources (what project isn't?) then I'm not sure what the next best would be.

I am of the opinion that just blindly closing bugs based on an age isn't very responsible. Though practically there are probably bugs that you will never get to. Marking them won't fix accordingly is appropriate.

Re: How should a bug tracker be managed?

Posted: Fri Oct 26, 2018 7:47 am
by gimmeapill
Regarding item #2:
ssj71 wrote:Trying to summarise various suggestions about how to avoid "necro-bugs" included:
* assuming every issue older than X years is a won't-fix and closing it (assuming users will re-open a bug if needed)
This is not exactly what I meant. Just cold closing is also bad, so let's rephrase slightly that one:
"Closing as won't fix, with a closing note to users informing them that you *think* that the bug is not relevant anymore (or at least not fixable on the old version) and basically ask them to reconfirm if their issue still happens with currently supported version of the product.
It is important that the bug reporter receives the notification (this is best done via automatic status change notification, as in most ticketing systems). This is actually the only part where we have to rely on an assumption.

Possible outcomes
- User doesn't come back because the issue is fixed (or because he doesn't care anymore). Working on that would have been wasted time anyway.
- User either comes back and the ticket is either reopened and linked against the new version, or the old one stays dead and a new ticket is opened.
- User doesn't come back because they don't receive the notification. Not very good, but then they wouldn't be able to confirm either that the issue is fixed soo... at least they might see someday the closure note if they come check the bug tracker.

Advantages:
- Saves developer time by not having to work on outdated issues.
- Getting in touch with end users is usually appreciated, even if this is through a canned closure note - as long as it acknowledges that the issue was not dealt with in time.
- keeping the number of open tickets to a manageable amount (if they are not gonna get touched, why keep them opened in the first place).

I practiced this method as a last resort in a professional context (service desk & first line SW support), and it usually fares quite well for the things in the bottom drawer that no developer would touch with a two meter pole - at least better than doing nothing.

Outside of the ticketing part, what I think is the worst is to work on old stuff without double checking with the user who reported it (that would be for the third option), since this could be purely wasted time.
Here, a simple note like "Hi I'm going to work on your issue, can you confirm if it's still there?" does work a long way.

Re: How should a bug tracker be managed?

Posted: Fri Oct 26, 2018 2:57 pm
by ssj71
gimmeapill wrote:Outside of the ticketing part, what I think is the worst is to work on old stuff without double checking with the user who reported it (that would be for the third option), since this could be purely wasted time.
Here, a simple note like "Hi I'm going to work on your issue, can you confirm if it's still there?" does work a long way.
thats a good point

Re: How should a bug tracker be managed?

Posted: Fri Oct 26, 2018 3:13 pm
by fundamental
gimmeapill wrote:- User doesn't come back because the issue is fixed (or because he doesn't care anymore). Working on that would have been wasted time anyway.
It is only a waste of time if the user is the only one impacted by the issue. It is very common for users to report bugs which impact many users and then over time lose interest in a project. Even though they have lost interest, others benefit from the fix and tracking of the issue. The majority of issues should not require the original user to verify a fix. If a ticket is made such that only one individual can verify, then I'd agree, but more often than not those are tickets without the needed steps to replicate/expected behavior and should be closed eagerly if users don't supply additional details.
- User either comes back and the ticket is either reopened and linked against the new version, or the old one stays dead and a new ticket is opened.
While this situation can be the best situation for an overwhelmed project, it will essentially spend good will with the users motivated enough to report bugs.
- keeping the number of open tickets to a manageable amount (if they are not gonna get touched, why keep them opened in the first place).
I'm split here. I like the notion of keeping tickets to a reasonable number, though quite often what happens is that each dev has their own "yeah, I'll work on this sooner or later list" and other open tickets fall into the "someone else can get to that eventually" category. Leaving tickets open for individuals not currently involved in the project can be valuable, though it can impact outside perceptions.
Here, a simple note like "Hi I'm going to work on your issue, can you confirm if it's still there?" does work a long way.
At larger scales I could see that making sense, though for intermittent open source work you would not typically want to deal with the communication latency inherent in emails reaching that person and them responding. For most issues you would be able to access them (to see if they're valid) much faster than the communications would take.
ssj71 wrote: Should a non-developer volunteer to contribute bug management I think probably the 3rd would be what to strive for, but if a project is lacking resources (what project isn't?) then I'm not sure what the next best would be.
A followup question to that notion, is: How do you make bug triage an appealing/easy-to-get-into task for contributors? Doing it correctly seems like it would be political, involve a lot of communication with project members, and require solid communication skills/knowledge of project conventions. I see it mentioned in all sorts of open source contribution guides, but it seems like a pretty complex thing to just hop in the middle of.

Re: How should a bug tracker be managed?

Posted: Fri Oct 26, 2018 9:53 pm
by ssj71
fundamental wrote:
ssj71 wrote: Should a non-developer volunteer to contribute bug management I think probably the 3rd would be what to strive for, but if a project is lacking resources (what project isn't?) then I'm not sure what the next best would be.


A followup question to that notion, is: How do you make bug triage an appealing/easy-to-get-into task for contributors? Doing it correctly seems like it would be political, involve a lot of communication with project members, and require solid communication skills/knowledge of project conventions. I see it mentioned in all sorts of open source contribution guides, but it seems like a pretty complex thing to just hop in the middle of.
For sure this takes a lot of communication with developers. Once a trusted relationship is set up it would naturally get smoother, but its definitely a challenge if you want to attract anyone who may not want to dedicate a lot of time/long term relationship to the project. If we could come up with a recipe for how one might waltz in, follow the recipe to basically determine if an old bug still applies, that would save a dev a lot of time. Perhaps though it's too non-linear a task to surmise in a list.