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.