From The Document Foundation Wiki
< QA‎ | Bugzilla‎ | Fields
Jump to: navigation, search

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

Getting Started

Whiteboard image.png

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.


  • Use wimpyCaps⁠Wikipedia logo v3.svg 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!



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.





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.




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.




Description: Used when the issue is an interoperability issue with Microsoft Office.

Use: To be used if the issue is with a Microsoft Office format (doc/docx, xls/xlsx, etc . . .).


Description: Tells future viewers of a bug which comment has the best description of the bug. Ideally, the comment should have clear reproducible steps to reproduce the bug.

Use: Can be used by anyone who sees a comment that is a better description of the bug than the original bug report.




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.


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.