This week I have a story to share about filing bug reports -why they're important, and what makes a "good" one. Last time, (sorry for the delay between posts!) I wrote about some Teams-related tips.
I've written several tidbits before where I file a bug report, but I have an exciting update to share - one of the bugs I filed has recently been fixed as a direct result of my report!!
In February of 2020 I wrote about a bug I had discovered where Android Studio's "quick fix" suggestion for Kotlin-based classes that derive from Android view components dangerously auto-generate a constructor with the @JvmOverloads annotation which causes the default style/theme properties to be ignored.
The report describing the bug is here: https://issuetracker.google.com/issues/149986188
What's the lesson to be learned here? Aside from my original caution around using @JvmOverloads, what I would like to impart this time is around how to write a good bug report. This is really one of the key differences between the bugs that get fixed and the ones that get ignored.
So, what goes into a good bug report?
A clear description of the problem - if people can't understand what you're talking about, it will be disregarded very early on in the process. The trick is to be very precise about what the issue is, with a sufficient level of detail - as a developer, I've seen bug reports that say " doesn't work" - that's not good enough. Also try to specify exactly what versions of all components you are using (Android Studio, Kotlin, libraries, phone make/model, OS, etc.), and if you can, do a little extra testing to determine and be able to explain what configurations may be impacted by this issue.
An easily reproducible test case - it's one thing to understand what the problem is, but you can greatly boost the likelihood of your issue being addressed if you do a little extra work to put together a sample project that clearly demonstrates the issue. Don't just upload a copy of your entire project - the smaller/simpler an example you can provide, the better.
A description of what the expected behavior should be - if the person investigating your bug has followed you through the first 2 items above, but you haven't spelled out what you think should happen, your bug may not get worked on - they may believe that it "functions as designed". This is where you can use some persuasive/logical arguments to clearly explain why the current behavior is wrong, and what it should do instead.
Double-check your bug report for errors (logical errors, missing information, typos, poor grammar, etc.) If there are bugs in your bug report, it's not going to be taken as seriously - so be sure to double-check it for errors, and try to write it in a professional tone. Using full sentences with proper capitalization, etc. eliminates the hurdle of the person reading it possibly concluding that you don't know what you're talking about.
Publicize the issue and get other people on board - the more people who are clearly affected by the issue, the more highly it will be prioritized. So, once you have submitted the issue, share it as broadly as you are able - tell your coworkers past & current and ask them to do the same, and consider writing an article about it to increase its visibility.
Follow the above steps, and with any luck, your issue will be resolved! The quality of especially open source projects increasingly relies on members of the community reporting the issues they're experiencing. And, if it seems like your bug is taking a long time to be fixed, consider trying to resolve it yourself! Open source projects often have limited developer resources, so if you provide a solid fix for the issue yourself (or at least have done some research into the cause and provide a suggestion for how to fix it), this can be another helpful boost towards getting the issue resolved.
Finally, note that the above suggestions don't just apply to external bug reports - these same strategies can be used to supercharge your internal bug reports as well!
For reference, here are two other Android Studio bugs I have filed previously which have also been resolved (both of these indirectly, but it can still be helpful the project's developers to provide additional data points):
https://issuetracker.google.com/issues/131403382
https://issuetracker.google.com/issues/143971679
Interested in working with me in the awesome Digital Products team here at Accenture? We have several open roles, including:
- Mobile Developer #1 (Northeast locations)
- Mobile Developer #2 (Northeast locations)
- Engineering Director (Boston or Philadelphia)
- Senior iOS Developer (Southern locations)
- Android Mobile Developer (Southern locations)
- iOS Mobile Development Lead (Southern Locations)
Do you have other suggestions for how to write a good bug report? Let me know in the comments below!
Top comments (0)