Understanding a Bug
*******************
The core of Bugzilla is the screen which displays a particular bug.
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.
*Summary:*
A one-sentence summary of the problem, displayed in the header next
to the bug number.
*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.
*Alias:*
A unique short text name for the bug, which can be used instead of
the bug number.
*Product and Component*:
Bugs are divided up by Product and Component, with a Product having
one or more Components in it.
*Version:*
The "Version" field usually contains the numbers or names of
released versions of the product. It is used to indicate the
version(s) affected by the bug report.
*Hardware (Platform and OS):*
These indicate the computing environment where the bug was found.
*Importance (Priority and Severity):*
The Priority field is used to prioritize bugs, either by the
assignee, or someone else with authority to direct their time such
as a project manager. It's a good idea not to change this on other
people's bugs. The default values are P1 to P5.
The Severity field 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 Milestone:*
A future version by which the bug is to be fixed. e.g. The Bugzilla
Project's milestones for future Bugzilla versions are 4.4, 5.0,
6.0, etc. Milestones are not restricted to numbers, thoughâyou can
use any text strings, such as dates.
*Assigned To:*
The person responsible for fixing the bug.
**QA Contact:*
The person responsible for quality assurance on this bug.
*URL:*
A URL associated with the bug, if any.
**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. "crash" or "regression".
*Personal Tags:*
Unlike Keywords which are global and visible by all users, Personal
Tags are personal and can only be viewed and edited by their
author. Editing them won't send any notifications to other users.
Use them to tag and keep track of sets of bugs that you personally
care about, using your own classification system.
*Dependencies (Depends On and Blocks):*
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.
Clicking the Dependency tree link shows the dependency
relationships of the bug as a tree structure. You can change how
much depth to show, and you can hide resolved bugs from this page.
You can also collapse/expand dependencies for each non-terminal bug
on the tree view, using the [-]/[+] buttons that appear before the
summary.
*Reported:*
The person who filed the bug, and the date and time they did it.
*Modified:*
The date and time the bug was last changed.
*CC List:*
A list of people who get mail when the bug changes, in addition to
the Reporter, Assignee and QA Contact (if enabled).
*Ignore Bug Mail:*
Set this if you want never to get bugmail from this bug again. See
also Email Preferences.
**See Also:*
Bugs, in this Bugzilla, other Bugzillas, or other bug trackers,
that are related to this one.
*Flags:*
A flag is a kind of status that can be set on bugs or attachments
to indicate that the bugs/attachments are in a certain state. Each
installation can define its own set of flags that can be set on
bugs or attachments. See Flags.
**Time Tracking:*
This form can be used for time tracking. To use this feature, you
have to be a member of the group specified by the timetrackinggroup
parameter. See Time Tracking for more information.
Orig. Est.:
This field shows the original estimated time.
Current Est.:
This field shows the current estimated time. This number is
calculated from "Hours Worked" and "Hours Left".
Hours Worked:
This field shows the number of hours worked.
Hours Left:
This field shows the "Current Est." - "Hours Worked". This value
+ "Hours Worked" will become the new Current Est.
%Complete:
This field shows what percentage of the task is complete.
Gain:
This field shows the number of hours that the bug is ahead of
the "Orig. Est.".
Deadline:
This field shows the deadline for this bug.
*Attachments:*
You can attach files (e.g. test cases or patches) to bugs. If there
are any attachments, they are listed in this section. See
Attachments for more information.
*Additional Comments:*
You can add your two cents to the bug discussion here, if you have
something worthwhile to say.
Flags
=====
Flags are a way to attach a specific status to a bug or attachment,
either "+" or "-". The meaning of these symbols depends on the name of
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.
A set flag appears in bug reports and on "edit attachment" pages with
the abbreviated username of the user who set the flag prepended to the
flag name. For example, if Jack sets a "review" flag to "+", it
appears as Jack: review [ + ].
A requested flag appears with the user who requested the flag
prepended to the flag name and the user who has been requested to set
the flag appended to the flag name within parentheses. For example,
if Jack asks Jill for review, it appears as Jack: review [ ? ] (Jill).
You can browse through open requests made of you and by you by
selecting My Requests from the footer. You can also look at open
requests limited by other requesters, requestees, products,
components, and flag names. Note that you can use '-' for requestee to
specify flags with no requestee set.
A Simple Example
----------------
A developer might want to ask their manager, "Should we fix this bug
before we release version 2.0?" They might want to do this for a *lot*
of bugs, so they decide to streamline the process. So:
1. The Bugzilla administrator creates a flag type called
blocking2.0 for bugs in your product. It shows up on the Show Bug
screen as the text blocking2.0 with a drop-down box next to it. The
drop-down box contains four values: an empty space, "?", "-", and
"+".
2. The developer sets the flag to "?".
3. The manager sees the blocking2.0 flag with a "?" value.
4. If the manager thinks the feature should go into the product
before version 2.0 can be released, they set the flag to "+".
Otherwise, they set it to "-".
5. Now, every Bugzilla user who looks at the bug knows whether or
not the bug needs to be fixed before release of version 2.0.
About Flags
-----------
Flags can have four 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".)
"_"
"unset" actually shows up as a blank space. This just means that
nobody has expressed an opinion (or asked someone else to express
an opinion) about the matter covered by this flag.
Flag Requests
-------------
If a flag has been defined as requestable, and a user has enough
privileges to request it (see below), the user can set the flag's
status to "?". This status indicates that someone (a.k.a. "the
requester") is asking someone else to set the flag to either "+" or
"-".
If a flag has been defined as specifically requestable, a text box
will appear next to the flag into which the requester may enter a
Bugzilla username. That named person (a.k.a. "the requestee") will
receive an email notifying them of the request, and pointing them to
the bug/attachment in question.
If a flag has *not* been defined as specifically requestable, then no
such text box will appear. A request to set this flag cannot be made
of any specific individual; these requests are open for anyone to
answer. In Bugzilla this is known as "asking the wind". A requester
may ask the wind on any flag simply by leaving the text box blank.
Attachment Flags
----------------
There are two types of flags: bug flags and attachment flags.
Attachment flags are used to ask a question about a specific
attachment on a bug.
Many Bugzilla installations use this to request that one developer
review another developer's code before they check it in. They attach
the code to a bug report, and then set a flag on that attachment
called review to review? reviewer@example.com. reviewer@example.com is
then notified by email that they have to check out that attachment and
approve it or deny it.
For a Bugzilla user, attachment flags show up in three places:
1. On the list of attachments in the Show Bug screen, you can see
the current state of any flags that have been set to "?", "+", or
"-". You can see who asked about the flag (the requester), and who
is being asked (the requestee).
2. When you edit an attachment, you can see any settable flag,
along with any flags that have already been set. The Edit
Attachment screen is where you set flags to "?", "-", "+", or unset
them.
3. Requests are listed in the Request Queue, which is accessible
from the My Requests link (if you are logged in) or Requests link
(if you are logged out) visible on all pages.
Bug Flags
---------
Bug flags are used to set a status on the bug itself. You can see Bug
Flags in the Show Bug and Requests screens, as described above.
Only users with enough privileges (see below) may set flags on bugs.
This doesn't necessarily include the assignee, reporter, or users with
the editbugs permission.
======================================================================
This documentation undoubtedly has bugs; if you find some, please file
them here.
