The core of Bugzilla is the screen which displays a particular + bug. It's a good place to explain some Bugzilla concepts. + Bug 1 on Landfill + + is a good example. Note that the labels for most fields are hyperlinks; + clicking them will take you to context-sensitive help on that + particular field. Fields marked * may not be present on every + installation of Bugzilla.
Product and Component: + Bugs are divided up by Product and Component, with a Product + having one or more Components in it. For example, + bugzilla.mozilla.org's "Bugzilla" Product is composed of several + Components: +
| Administration: + Administration of a Bugzilla installation. |
| Bugzilla-General: + Anything that doesn't fit in the other components, or spans + multiple components. |
| Creating/Changing Bugs: + Creating, changing, and viewing bugs. |
| Documentation: + The Bugzilla documentation, including The Bugzilla Guide. |
| Email: + Anything to do with email sent by Bugzilla. |
| Installation: + The installation process of Bugzilla. |
| Query/Buglist: + Anything to do with searching for bugs and viewing the + buglists. |
| Reporting/Charting: + Getting reports from Bugzilla. |
| User Accounts: + Anything about managing a user account from the user's perspective. + Saved queries, creating accounts, changing passwords, logging in, + etc. |
| User Interface: + General issues having to do with the user interface cosmetics (not + functionality) including cosmetic issues, HTML templates, + etc. |
Status and Resolution: + + These define exactly what state the bug is in - from not even + being confirmed as a bug, through to being fixed and the fix + confirmed by Quality Assurance. The different possible values for + Status and Resolution on your installation should be documented in the + context-sensitive help for those items.
Assigned To: + The person responsible for fixing the bug.
*URL: + A URL associated with the bug, if any.
Summary: + A one-sentence summary of the problem.
*Status Whiteboard: + (a.k.a. Whiteboard) A free-form text area for adding short notes + and tags to a bug.
*Keywords: + The administrator can define keywords which you can use to tag and + categorise bugs - e.g. The Mozilla Project has keywords like crash + and regression.
Platform and OS: + These indicate the computing environment where the bug was + found.
Version: + The "Version" field is usually used for versions of a product which + have been released, and is set to indicate which versions of a + Component have the particular problem the bug report is + about.
Priority: + The bug assignee uses this field to prioritise his or her bugs. + It's a good idea not to change this on other people's bugs.
Severity: + This indicates how severe the problem is - from blocker + ("application unusable") to trivial ("minor cosmetic issue"). You + can also use this field to indicate whether a bug is an enhancement + request.
*Target: + (a.k.a. Target Milestone) A future version by which the bug is to + be fixed. e.g. The Bugzilla Project's milestones for future + Bugzilla versions are 2.18, 2.20, 3.0, etc. Milestones are not + restricted to numbers, thought - you can use any text strings, such + as dates.
Reporter: + The person who filed the bug.
CC list: + A list of people who get mail when the bug changes.
Attachments: + You can attach files (e.g. testcases or patches) to bugs. If there + are any attachments, they are listed in this section.
*Dependencies: + If this bug cannot be fixed unless other bugs are fixed (depends + on), or this bug stops other bugs being fixed (blocks), their + numbers are recorded here.
*Votes: + Whether this bug has any votes.
Additional Comments: + You can add your two cents to the bug discussion here, if you have + something worthwhile to say.