Once a community project gathers some momentum, you need a formal process for managing issues and feature requests. No development team can hope to capture ideas, and bugs through a miasma of emails, forum posts and instant messages. Enter the bug database.
The bug database is a font of project knowledge, harbouring bugs, workarounds, feature requests, road maps and more. But they can be an absolute bugger to manage. It can be a full time job just classifying, annotating and verifying issues, let alone prioritising them for fixes and scheduling resources.
As a user, you can make a difference by correctly reporting issues as and when you find them. As a community, you can make a huge impact by collectively contributing to the quality of data in the bug database -- here’s how.
Publicise and vote.
A project of any size will always have bugs and feature requests waiting to be addressed. Developers will nearly always tackle those things that interest them first but we’re not oblivious to the needs of the community. We take pride in our code and are always interested in new ideas. Typically we just need a nudge in the right direction.
If you have a problem search the bug database -- chances are someone else has already encountered the same issue. If it impacts you, say so. Vote for the bug. I mean how hard is that? Popular bugs and features generally get fixed before bugs no one has ever heard of.
Make people aware of the bug that concerns you. Most developers on a team are only focused on the bugs that affect them or the bugs assigned to them. Report the bug (and its number) to the forums, explaining why its impacting your development. Be polite. Publicising a bug may be all that’s needed to bring it to the attention of the right developer.
(Note: Don’t expect a guaranteed response, unless you’re prepared to pay for the fix.)
There are so many different computer environments and set ups. Just because you are seeing a bug doesn’t mean everyone else is. If you have a problem, search the bug database and add the issue if its not there.
There’s nothing more frustrating than hearing someone talk about how a bug has been around since x version and they are sick having to fix it every time a new release comes out. Not reporting a bug is selfish and lazy. Patching and not reporting a bug is just plain scum bag behaviour. Making smug comments on a project forum about how the bug should have been fixed aeons ago is a hanging offence.
Report bugs - it’s not hard.
If I can’t see it, I can’t fix it.
Getting to grips with the bug database? You might take the next step and report bugs properly. The basic essence of bug fixing is the ability to reproduce the bug. It may surprise you that one of the most time consuming elements of any fix, is trying to work out what the bug is in the first place.
When you report an issue, make sure you provide the exact steps taken to reproduce it. If you see your issue already in the bug database, add your own specific details to the ticket. If it’s a user interface issue make sure you include a screen shot. The more information the better. Details of your environment, operating system, web browser, even the time of day - it can all be relevant.
Confession: any bug that I find that cannot be faithfully reproduced is downgraded or deleted. It’s just not worth the time to look at poorly described bugs.
Of course if you can provide a fix to a bug, make sure you add it to your ticket. I almost always make a rule of notifying the developers that I have a suggested fix. Nothing worse than having your beautiful patch sitting in an unknown ticket for months when it might have made into version control the next day.
Different projects like fixes reported in different ways. Personally I think a snippet of code is one of the worst ways. Report the specific fix in a comment by all means but always attach the complete file or files. These days diffing programs make it easy for committers to review your changes and incorporate them into the code base as appropriate.
Related Blog Posts