Not all 'bugs' are bugs. Some items in the database are known as Enhancement Requests or Requests For Enhancement (RFE). An RFE is a bug whose severity field is set to 'enhancement'. People often say 'bug' when they mean 'item in Bugzilla', so RFEs often wind up being called bugs.

Enter the tasks you're planning to work on as enhancement requests and Bugzilla will help you track them and allow others to see what you plan to work on. If people can see your flight plan, they can avoid duplicating your work and can possibly help out or offer feedback.

Looking for the source of Bugzilla? If you want to set up a Bugzilla on your own server, you can get it http://www.bugzilla.org/ - here .

Anatomy Of A Bug

Bugs and RFEs are composed of many fields. Some of them are described here.

Component

The Mozilla application is composed of many different components such as the networking library, javascript, and the layout engine. Carefully read the https://bugzilla.mozilla.org/describecomponents.cgi - component descriptions if you're unsure of which component to attribute your bug to. Some components are very similar. For example, problems with table layout should be assigned to HTML Tables, not to Layout. The component you choose determines which person Bugzilla assigns the bug to.

Status Whiteboard

The Status Whiteboard is used for writing short notes about the bug.

Keywords

This field is used to store various

https://bugzilla.mozilla.org/describekeywords.cgi - keywords . For instance, the http://www.mozilla.org/newlayout/bugathon.html - BugAThon uses it to to note when bugs have test cases (using the keyword testcase).

helpwanted

Developers can use this field for posting helpwanted notices. Write helpwanted in the Keywords field of one of your bugs or RFEs and others searching for things to do will find it. People interested in http://www.mozilla.org/get-involved.html - getting involved can search Bugzilla for bugs and RFEs marked helpwanted. Maybe one of them will have the expertise and resources to help you with your problem.

For instance, if your code has a bug on some platform which you don't have access to, or with some language you don't know, try adding this keyword.

Or, as with any developer, you're probably swamped with bugs. Some of these bugs will be lower priority than others. Try marking bugs that you realize you won't be able to any time soon as helpwanted. Someone else with different priorities may see this and help you out.

When marking bugs (or RFEs) helpwanted, be sure to add a comment carefully explaining what work needs to be done, and how to do it, if you know. The better you can explain the problem and its solution, the more likely it is that someone can provide a useful solution.

Target Milestone

The Mozilla project uses target milestones to plan Mozilla's development process. If a bug is marked mozilla1.3, it means an assigned developer picked Mozilla 1.3 as his/her estimate of the earliest milestone at which that bug might be resolved. This field should only be set by the person responsible for the bug.

Dependency

If a bug can't be fixed until another bug is fixed, that's a dependency. For any bug, you can list the bugs it depends on and bugs that depend on it. Bugzilla can display a dependency graphs which shows which the bugs it depends on and are dependent on it.

Attachment

Adding an attachment to a bug can be very useful. Test cases, screen shots and http://www.mozilla.org/editor/logging/api-logging.html - editor logs all can help pinpoint the bug and help the developer reproduce it. If you fix a bug, attach the patch to the bug. This is the preferred way to keep track of patches since it makes it easier for others to find and test. To make a patch, you need to generate a diff file containing the differences between the file with your changes and the original file in the repository. To generate a patch file enumerating changes for all files in the current directory try cvs diff -u > mypatch.diff. To apply a patch, go to the proper directory and patch < bugpatch.diff.

Life Cycle Of A Bug

What happens to a bug when it is first reported depends on who reported it. New Bugzilla accounts by default create bugs which are UNCONFIRMED - this means that a QA (Quality Assurance) person needs to look at it and confirm it exists before it gets turned into a NEW bug.

If you have been working in Bugzilla for a while and believe you are worthy of being able to create NEW bugs, mail http://www.gerv.net/hacking/before-you-mail-gerv.html - Gerv . When a bug becomes NEW, the developer will probably look at the bug and either accept it or give it to someone else. If the bug remains new and inactive for more than a week, Bugzilla nags the bug's owner with email until action is taken. Whenever a bug is reassigned or has its component changed, its status is set back to NEW. The NEW status means that the bug is newly added to a particular developer's plate, not that the bug is newly reported.

Those to whom additional permissions have been given have the ability to change all the fields of a bug (by default, you can only change a few). Whenever you change a field in a bug it's a good idea to add additional comments to explain what you are doing and why. Make a note whenever you do things like change the component, reassign the bug, create an attachment, add a dependency or add someone to the CC list. Whenever someone makes a change to the bug or adds a comment, the owner, reporter, the CC list and those who voted for the bug are sent an email (unless they have switched it off) showing the changes to the bug report.

If you are doing much work in Bugzilla, you might want to check out the http://www.mozilla.org/quality/help/ - QA Help Page , which has various useful resources and things to do.

When a bug is closed it's marked RESOLVED and given one of the following resolutions.

FIXED

A fix for this bug has been checked into the tree and tested by the person marking it FIXED.

INVALID

The problem described is not a bug, or not a bug in Mozilla.

WONTFIX

The problem described is a bug which will never be fixed, or a problem report which is a "feature", not a bug.

DUPLICATE

The problem is a duplicate of an existing bug. Marking a bug duplicate requires the bug number of the duplicating bug and will add a comment with the bug number into the description field of the bug it is a duplicate of.

WORKSFORME

All attempts at reproducing this bug in the current build were futile. If more information appears later, please re-open the bug, for now, file it.

http://www.mozilla.org/quality/ - QA (this could be you - check out http://www.mozilla.org/quality/help/ - the QA help page ) looks at resolved bugs and ensures the appropriate action has been taken. If they agree, the bug is marked VERIFIED. Bugs remain in this state until the product ships, at which time the bug is marked CLOSED. Bugs may come back to life by becoming REOPENED.

Be careful when changing the status of someone else's bugs. Instead of making the change yourself, it's usually best to make a note of your proposed change as a comment and to let the bug's owner review this and make the change themselves. For instance, if you think one bug is a duplicate of another, make a note of it in the 'Additional Comments' section.

If you make a lot of useful comments to someone's bugs they may come to trust your judgement and ask you to go ahead and make the changes yourself, but unless they do, it's best to be cautious and only make comments.