Bugzilla: Open Source Bug-Tracking System - General Overview, Continued
(Page 3 of 4 )
Bugzilla can be adapted to virtually all kinds of projects without exceptions. Users can access powerful and varied search engine functions. There’s the “simple” search, but there is also an “advanced” search. These functions search the database for previous bugs, their fixes, patches, and lots of additional details. The advanced search gives users the ability to explicitly specify the target fields from the database.
Thankfully, the web user interface can be customized with templates because, by default, it looks quite plain, washed out, and way too simplistic. Lots of people go so far as to claim it is utterly ugly. It definitely isn’t decent at all in terms of “looks,” but its functionality and usability far outweighs its aesthetics. And the problem is that very few administrators actually create their own template for a “makeup retouch.”
Submitting a new bug is a very simple process. There are target text-fields to fill out, along with drop-boxes full of options. Basically, the product name must be picked, its version number, the specific platform on which it is being used, the operating system, its state, severity, etc. It is quite interesting to see that you can assign the bug to a particular developer. But usually it’s advisable to leave it up to the development team to choose who works on the bug.
The workflow model of a new bug, meaning the life cycle of a bug, cannot be customized. Since Bugzilla was one of the first free issue-tracking systems in the open source world, their “style” was adopted by hundreds of companies, and ultimately it has become an unwritten standard that this is the way bugs should be handled. Why should we change the workflow as long as it has been proven to be productive?
You can read more about this workflow model in this manual at page 68. In short, the process goes like this. A new bug is submitted, and its “state” becomes unconfirmed, new, or assigned. A developer picks up the bug, and then it becomes assigned. After this point we can assume that s/he actually looks into the issue.
Developers can provide an answer to the bug by changing its state to either of the following: fixed, duplicate, wontfix, worksforme, or invalid. Let’s presume that the said bug is fixed; then its status is set appropriately and a fix is provided. Ultimately, this doesn’t mean that the issue is closed. Another release ought to be done in which the fix is included, but before that a quality assistant verifies the provided fix (checking to see whether it really fixes the reported bug, how the fix behaves on various platforms, and such).
Bugzilla, like other issue tracking and project management systems, also offers the ability to create graphs, charts, and various reports based on statistics and data. These pie or line charts are quite useful but are by no means fancy. They are just that—charts—and nothing more.
Moreover, there is an interesting voting feature where customers and/or users can submit their opinions to request a new function or feature from the developers. This part vastly improves communication between customers and developers. The voting mechanism illustrates whether the proposed idea is a good one.
