Over the years I’ve tried several bug tracking applications and Bugzilla is by far my favorite. It’s a great tool for all sorts of projects, whether they’re open source or not. It’s proven its ability to handle thousands of bugs for many different projects with ease as it’s the bug tracking tool that the Mozilla Foundation prefers. Yet how can single developers who work on small to medium-sized web-based applications use this tool without sacrificing much time managing it? I’ve worked out which features are useful and which are not to me, as I am one of those free-lance programmers.

Users/Groups

My installation of Bugzilla 2.20rc1 is on a local test server, so there is only one user I have to manage – myself. Right away I really don’t have to worry about user or group permissions, because I just give myself access to everything. Depending on what exactly you contract for, you may need to allow your clients to access and run queries on your database – but that’s not much extra work at all. For my type of business, the technical reports are for me and would be too confusing for my clients. If ever there was a need for them to see details, it’s just a copy-and-paste away.

I really haven’t found it useful to mark a bug either new or assigned, and managing those assignments is pretty pointless with only a single user. For me it’s either unresolved, resolved, or closed.

Products

My products are generally small to medium-sized web-based applications that typically do not take longer than a month to work on. Sometimes I have larger applications that take a year or more of work, so I need flexibility in both my scheduling, bug tracking, and revision control to manage all of my pending workflow. Bugzilla makes it very easy for me to keep track of each project. Each new project I begin for a client, I create a new product for in Bugzilla. My rule on separating code and projects is that if the code I write is completely separate from any other code I’ve written for that same client, it gets it’s own product entry. If I’m just adding a new module to an existing project, I’ll simply add a new component to the product listing in bugzilla.

From there, I just use components, version numbers, and target milestones the same way everyone else does. I do use CVS (maybe someday I’ll go to Subversion) for basic revision control of these projects. My guideline on entering code to CVS and creating a product in bugzilla is that:

• If it’s a small project, I can enter the code once I have a beta (ready for external testing) complete.
• If it’s a large project, I’ll enter it the moment I get a good foundation (I use a framework I’ve created, so pretty much I’ll commit it immediately).

If I don’t follow those basic guidelines I’ll have a huge project with a million things to do – which means I would get sucked into the black hole of entering obvious to-dos instead of actual bugs. A contractor must use their time wisely, and using bugzilla for something more than BUGS is just a waste of time. It’s tough for me to not use it as a to-do list, but it’s much easier to manage issues versus features requests when I stick to that principle.

Tags

The most wonderful thing about bugzilla is the ability to categorize bugs by using labels. These tags make managing my “queue” of pending work amazingly easy. This is where the fun begins.

blocking-1.0.0

Most applications I’ve seen use tags to identify which bugs are so important that the next update/version should be held until they’re resolved. It’s a great method, especially when you use them with the priority fields for individual bugs. Though this is helpful for contractors developing small applications, it’s better to use them to identify bugs that the client has to have fixed before they’ll accept the product. The product may work as expected without some of them being resolved, which is not really what a blocking bug is for, but it’s useful in identifying what has to be cleared out before product delivery.

This tag really must be created for each product.

research-required

I use this tag as a global tag (applicable to all products) to signify bugs I need to research before I can begin any work. Maybe I need to read a tutorial, a reference manual specification, or just peruse some sample syntax. It allows me to easily to see what I need to know before I go in and develop anything. Pulling all products at once with this tag applied allows me to do all of the research when I have time. It also can help me when a client is asking for an idea on how much time remains until I’ve got a product they can look at – if I know I have four bugs and not one clue how to fix them, I can avoid giving a false timeframe. This has been a life saver!

easy-fix

Many project management experts advise you to do something right now if it will take you less than two minutes to complete. This is a very good tip for both real life and the development word. If I have a bug or change request that really would take less than two minutes to fix – mainly layout or text issues – I’ll pull this list and do a fix-spree. How many of these can I clear out of my “queue” in the next half hour? I’m surprised at the amount of bugs I can clear out with a simple pull of bugs with that tag. I generally can focus much better if I do similar work all at once. If I have a list of easy-fix bugs, I can speed through all of them without taking much time to check for potential bugs – as they’re usually so easy that they don’t cause any new bugs to open.

Sometimes I’ve found it useful to also have a difficult-fix tag, to get the opposite listing of bugs. The more bugs you can clear out, the easier it will be to see what’s left. This really helps you plan out how much work you need to do before any deadlines, as well as making it easier to manage a queue of ten bugs rather than twenty.

next-target

Sometimes I’ll take set aside a huge chunk of a day to sit down and power-code. In order to maximize the time free for coding, I need to make sure all my bugs are in order before I do. Just like setting out an agenda for a meeting, identifying which bugs you need to tackle on your next work day is very important. If I scan through my list of bugs with either a blocking-something tag or a high priority, I can mark it as a next-target so that when I come in to begin working I have everything that needs to be done ASAP. I’ll print that report out, post it on the wall, and start the day! I just keep a red Sharpie handy to cross out what I’ve done, so that later I can update bugzilla!

This keeps me focused on what needs to be done now, as I don’t even see lower-priority fixes that I would prefer to work on. It’s really just a tool to eliminate distraction. Then I at the end of the day I can see how many important things are left, and then proceed to feel good or bad depending on my accomplishments.

Whining

I never played with this until recently, and I love it! As a contractor who doesn’t have all day to manage my bugzilla lists, I setup a few whining crons to email me when I have to do something. I see my lists of bugs as “queues” and as any effective-queue management expert knows, you need to keep them moving! I’ve setup a whine to email me a list of all of the bugs that I have not updated in two weeks. I am guilty of deleting one or two of these emails, but it’s important than I have an idea on how behind (or ahead) I am.

I also send myself a list of the bugs with the aforementioned tag “research-required” so if I happen to check email somewhere other than home, I have a reminder of something I could be doing.

What Would Make Bugzilla Perfect?

Previously I used Mantis for bug tracking, so the bugzilla status fields were a bit different and difficult to get used to when I first switched. I’m not at all keen on the bugzilla resolution fields – and how they’re used. I find it very confusing to mark a bug as “RESOLVED” with a resolution of “WONTFIX” or “INVALID” – because if I won’t fix it then it certainly isn’t resolved. Why would I want to mark something as RESOLVED when it’s not? I think there should only be one status field, with:

• NEW
• UNCONFIRMED
• CONFIRMED
• ASSIGNED
• RESOLVED
• CLOSED
• REOPENED
• DUPLICATE

That’s all anyone should really need, and it makes perfect sense.

I also love the way that Mantis utilizes a changelog feature – simply creating basic lists of bugs that are resolved grouped by their target milestone. Bugzilla really needs this. The problem now is that I can do a search for these, but if I change the format of the search results template, it’s changed for ALL search results. A special template and a separate changelog feature would be very handy – but for now, I decided to write a separate (basic) perl script for this.

The whine emails are very nice, but because my power-coding days are never consistent, I would like the ability to trigger an email with the click of a button. I can’t predict when some of these days will be and I don’t want to always be changing the crontab – so manually sending an email whenever I want would be nice.

If I had lots of time (and someday I might not be so busy) I would try to submit some patches to the Bugzilla source and see what the owners think. After all, the open source motto is to fill in where you see a need!

Conclusion

I hope I have outlined some good ideas for independent / free-lance programmers and how they can use bugzilla for their own use. Bug tracking, version control, and other items generally associated with larger projects can often very handy for small-time projects as well! I would appreciate any comments with alternate ideas, comments, and/or suggestions!