Jump to content

QA/Bugzilla/Fields/Whiteboard

From The Document Foundation Wiki


This page is about the Whiteboard (aka status_whiteboard) field in Bugzilla.

Getting Started

This page is for beginners and only has the basics of using the Whiteboard text box in Bugzilla. For a complete explanation with all Whiteboard tags please visit Advanced.

The Whiteboard text box has historically been where QA puts specific terms to help organize our bug tracker. We've recently migrated many common Whiteboard Tags to the Keywords field. While theKeywords field has a set list of allowed terms, there are no restrictions on what can go in the Whiteboard field. That being said, we do encourage users and QA to only use tags that are on the approved list.

Markup

  • Use wimpyCaps for all tags
    • i.e. first word lower-case, following words Upper-Case, and no inter-word spaces
  • Separate the tags by a space (e.g. "thisTag thatTag anotherTag")
  • Do NOT use commas in the whiteboard
  • Do NOT use the Whiteboard for random comments!

Confirmation

confirmed:VERSION:OS

Description: Can be used to say that the bug was confirmed on a particular OS and using a particular version of LibreOffice.

Use: Not frequently used but can be used when wanting to add more information to a confirmed bug. Should always include “confirmed:” then version and then OS.

Examples:

confirmed:4.1.3.2:ubuntu
confirmed:4.1.3.2:windows7
confirmed:4.2.0.1:macOS

Reproducibility

noRepro:VERSION:OS

Description: Used when you are unable to reproduce the bug but are not comfortable closing the bug as LINK

WORKSFORME. Includes information about what version was used and the operating system of the tester.

Use: Generally used when the testing environment is different than the testing environment of the bug reporter so closing the bug as WORKSFORME status is less applicable. Used mostly by QA members and developers.

Examples:

noRepro:4.1.3.2:Ubuntu
noRepro:4.1.3.2:Windows7
noRepro:4.2.0.1:macOS

needsSOFTWARE

Description: Used to highlight a particular piece of software that is required to triage the bug.

Use: Only used for unique software requirement. Not appropriate for “needsMSO” as Microsoft Office is relatively common but if the bug only affects Microsoft Office 2013 then using “needsMSO2013” is appropriate. Also not appropriate for “needsWindows” (setting version to “Windows(all)” is sufficient, but if a particular version of Windows is needed (such as XP) it is appropriate, please see more appropriate explanation at the section #Specific OS Requirement.

Examples:

needsAlfresco
needsDuplexPrinter
needsWebDAV
needsKDE
needsAppleNumbers

interoperability

Description: Used when the issue is an interoperability issue with Microsoft Office (doc/docx, xls/xlsx, etc . . .). Nowadays we use the keywords filter:[extension]

multipleBugs

Description: Use when a bug report has multiple bugs reported in a single bug report.

Use: Use if you decide to keep the bug report open for some reason (usually we close these as INVALID and ask the user to open individual reports for each issue) and are triaging a single issue out of all the issues reported. When confirming the issue make sure to address the issue that you were confirming in your comments and then tell the user to report new bugs for all other issues. Feel free to put “see also” in these bugs if they are dealing with the same document/attachment.

Bibisection

There are some legacy bibisect tags still present in the Whiteboard field, however most active bibisect-related tags have been migrated to Keywords.

Specific OS Requirement

Description: This field indicates a specific operating system needed for the bug.

Use: Should be used only if the bug is confirmed to only affect a specific OS.

Examples:

needsUbuntu
needsWindows8