Bugtrackers, tickets and squashing bugs is a process essential to every software engineer and it is expected, that you know the process. But somehow there is no proper description of the process and how it works. All knowledge about squashing bugs is self-taught or delivered in tales full of nostalgia.
In this article I explain my strategy on how to process bugs in an efficient manner. The goal of this process is not to close as many tickets as possible, but to solve the problems of the users and improve the software. Closing tickets and fewer tickets overall is a side effect.
Before you start
First you have to get an overview. This means reading tickets within the bugtracker. Depending on the ticket count, this can be many tickets you have to read. The goal is to get a feeling for how bugs get processed in this community. What is the general ticket quality? Do tickets get processed at all? Is there a proper problem analysis? Do they get assigned and then nothing happens for months? Look for obvious bottlenecks. This gives you an idea, on which specific tasks within the process you have to focus.
After this, it is time to devise a strategy. I like to work from old to new. Because old bugs usually contain a lot low hanging fruit. With that I mean tickets, that are obsolete, no one had a look at or are already fixed. Others prefer to process the ones without a reply first. This is entirely your decision. The important thing is to have a point of reference to measure progress.
Once you have prepared yourself, it’s time to get some actual work done.
The process
Now on to the actual Bug squashing! All you have to do, is pick a ticket and follow the process. After that, rinse and repeat. At times, you might feel like Don Quixote fighting Windmills, but you will make slow and steady progress and improve the open source ecosystem along the way.
-
Read the bug description and the comments. Have a look at the history, to see when the last change was made. The goal is to find out in which state the ticket is.
-
If it is obviously obsolete, close the ticket or request closure if you don’t have the rights to do so. It is obsolete when
- the referenced software does not exist anymore.
- the ticket is already solved. Sometimes it helps to request confirmation that it is solved and then close the ticket afterwards.
- the feature which is referenced in the ticket does not exist anymore or got changed in a fundamental way.
- the software version is not supported anymore. This may mean, that you have to try and reproduce the problem with a current version of the software. Please see the next step for more details.
Document your reason for closing the ticket. This makes your decision transparent to others.
-
Try to reproduce the problem described in the ticket. For this, check the version of the software with which the problem was reported. Then try to reproduce it with the original software version referenced in the ticket and after this with the current software version to verify the problem still exists. Document your findings. If your findings are inconclusive, ask others to also reproduce and verify your results.
-
Depending on the result of your attempt of reproduction there are two paths of action you can follow. The paths are described in the steps 5 and 6 respectively. No matter what the result, always document your findings as detailed as possible. It may help you or others later in the process.
-
The issue is reproducible: If there is an upstream repository, check upstream for a ticket with the same description, then either link the issues or create a new ticket upstream. If you are upstream you can try to fix the issue yourself or at least narrow down the root cause. If you are unable to fix it yourself, try to find someone you can delegate it to.
-
The issue is not reproducible: If you are unsure about your results, ask for confirmation by a second person. If you are confident that you did everything right, directly request closure.
-
If the issue is reproducible and you have the skills to fix it, do it. This will mean, that you have to create a patch and file a pull request. This may be time-consuming but also very rewarding. As a basic rule, always leave the code in a better state then you found it.
Edge cases
-
What happens if no one answers to your requests? For open source projects I use 4 weeks as a general deadline. If no one answers within the time frame, I try to directly contact the people involved. After another 4 weeks I close the issue if no one replied.
-
Not enough information is available: Find out what additional information is needed to properly investigate the issue. As a rule of thumb, request twice what you need and be happy if you get half of it. But also do not burden people with time-consuming extra work, if the return on investment isn’t worth it.
-
There are dependencies to other tickets: If there are dependencies to other tasks, make them explicit by referencing them bidirectional. Find the blocking tickets and try to move them forward until all dependencies are solved.
-
There are tickets you just can’t do anything about at the current time. Don’t get discouraged by them. Take note of them and move on to the next ticket you can do something about. You can always come back later and give it another try.
Conclusion
Before you start to work on a bugtracker, get an overview. Then you can start the actual work, which is about following the described process again and again. Bugtrackers and their communities are similar but also different. So please adapt the process described above to the community you are working with.