Classifications tend to be used in order to group several related products into one distinct entity.


Products tend to represent real-world shipping products. E.g. if your company makes computer games, you should have one product per game, perhaps a "Common" product for units of technology used in multiple games, and maybe a few special products (Website, Administration...).
Products have milestones. Target Milestones are Product goals. They are configurable on a per-Product basis. Most software development houses have a concept of "milestones" where the people funding a project expect certain functionality on certain dates. Bugzilla facilitates meeting these milestones by giving you the ability to declare by which milestone a bug will be fixed, or an enhancement will be implemented. Milestones are "targets" that you plan to get a bug fixed by. For example, you have a bug that you plan to fix for your 3.0 release, it would be assigned the milestone of 3.0.
Versions are the revisions of the product, such as "Flinders 3.1", "Flinders 95", and "Flinders 2000". Version is not a multi-select field; the usual practice is to select the earliest version known to have the bug.

A Component is a subsection of a Product. It should be a narrow category, tailored to your organization. All Products must contain at least one Component.

Components are subsections of a Product. E.g. the computer game you are designing may have a "UI" component, an "API" component, a "Sound System" component, and a "Plugins" component, each overseen by a different programmer. It often makes sense to divide Components in Bugzilla according to the natural divisions of responsibility within your Product or company.

Each component has a default assignee and (if you turned it on in the parameters), a QA Contact. The default assignee should be the primary person who fixes bugs in that component. The QA Contact should be the person who will ensure these bugs are completely fixed. The Assignee, QA Contact, and Reporter will get email when new bugs are created in this Component and when these bugs change. Default Assignee and Default QA Contact fields only dictate the default assignments; these can be changed on bug submission, or at any later point in a bug's life.

A "bug" in Bugzilla refers to an issue entered into the database which has an associated number, assignments, comments, etc. Some also refer to a "tickets" or "issues"; in the context of Bugzilla, they are synonymous.

Voting allows users to be given a pot of votes which they can allocate to bugs, to indicate that they'd like them fixed. This allows developers to gauge user need for a particular enhancement or bugfix. By allowing bugs with a certain number of votes to automatically move from "UNCONFIRMED" to "NEW", users of the bug system can help high-priority bugs garner attention so they don't sit for a long time awaiting triage. 

Bug detail


Flags are a way to attach a specific status to a bug or attachment, either "+" or "-". The meaning of these symbols depends on the text the flag itself, but contextually they could mean pass/fail, accept/reject, approved/denied, or even a simple yes/no. If your site allows requestable flags, then users may set a flag to "?" as a request to another user that they look at the bug/attachment, and set the flag to its correct status. Flags convey information on the quality of the support that the development community provides to the user community.

Flags can have three values:
(?) - A user is requesting that a status be set. (Think of it as 'A question is being asked')
(-)The status has been set negatively. (The question has been answered "no")
(+) - The status has been set positively. (The question has been answered "yes")
(<blank space>) - When the flag is unset, this just means that nobody has expressed an opinion (or asked someone else to express an opinion) about this bug or attachment.



Last modified: lundi, 15 juillet 2013, 4:35