Desktop Firefox Keyword/Flag usage

Bugzilla can seem to be a very complex tool for a beginner. This is a small guide intended to help you understand the meaning and usage of flags and keywords - from a QA point of view.

Flags are a way to attach a status or inquire about a specific status of a bug. Whereas keywords can be used to tag and categorise bugs.

Here’s a list of keywords, flags and their corresponding meaning and action items.

Tracking flags:

• tracking-firefoxN flag - This flag is used to track bugs for particular release cycles . It can have three different values:

1. "?" - used for inquiring whether a bug will be tracked for version N.
2. "+" - used for mark the fact that the bug is tracked for version N.
3. "-" - used for mark the fact that the bug is not tracked for version N.

• status-firefoxN - A multi-state flag which marks the status of the bug and progress of the bug fixing process on Firefox version N. The flag’s values are as follows:

1. unaffected - The bug does not affect the specified Firefox version.
2. affected - The bug affects the specified version.
3. fixed - The bug is fixed in the specified version.
4. wontfix - The bug is present but it has been decided it won't get fixed in the specified version.
5. verified - The bug is fixed and has been verified for the specified version.
6. disabled - The feature implemented in the bug is disabled for the specified version.
7. verified disabled - The disabling of the feature has been verified for the specified Firefox version.

QA-related flags:

• needinfo - a flag through which one can request information from anybody in Bugzilla. There are three possible values for this flag:

1. "?" - This is the value the flag takes when someone is requesting information. It usually comes with the name or email address of the person asked for information. IF no nobody is added to this flag, then the question is considered addressed to anybody that sees it. Whenever setting this flag, please make sure you state clearly what information you need.
2. "+" - Setting the flag with this value means that the request for information was resolved.
3. " -" - This value means that the request will not receive an answer. For example, one might have directed the question to the wrong person. In this case you can just re-set the flag to "?" and add someone else as the requestee.

• in-moztrap - indicates that the bug is nominated for a Moztrap testcase. This flag can also take one of three values:

1. "?" - the bug needs investigation into whether it needs a manual test case or not. If the bug does need it, then one will also investigate whether the test already exists in Moztrap or not. If it doesn't exist, it should be created.
2. "+" - indicates the bug has a Moztrap testcase.
3. "-" - indicates the bug does not need a Moztrap testcase.

• in-testsuite: indicates that the bug is nominated for an automated test. Values:

1. "?" - the bug needs investigation into whether it needs an automated test or not. If it does need it, then one will also investigate whether the test already exists and create it, if necessary.
2. "+" - the bug has an automated test.
3. "-" - the bug does not need an automated test.

QA-related keywords:

• qawanted - used to track bugs needing immediate QA attention. People outside of QA should use the qawanted keyword, in conjunction with a keyword categorizing the request.
• testcase-wanted - bugs which have this keyword would strongly benefit from a testcase or from additional testcases in order to get fixed. This keyword may indicate that any existing testcases are too complex and need to be reduced to much simpler tests in order to find or debug the source of the problem. Check the comments of the bug to discover exactly what is wanted.
• steps-wanted - bugs with this keyword need someone to identify reliable steps to reproduce them. Without reliable steps to reproduce a bug, it is extremely difficult to debug it and fix it.
• regressionwindow-wanted - it is needed for someone to narrow down the time period where the bug was introduced, ideally to a specific checkin. For more details on how to do this, see this QMO article and the MozRegression docs.