From The Document Foundation Wiki
    < QA‎ | Bugzilla‎ | Fields‎ | Whiteboard

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

    NOTE: Many of the Whiteboard tags have been migrated to the Keywords field.

    Getting Started

    Whiteboard image.png

    Note: This page is currently in progress

    The Whiteboard text box in bugzilla is where QA, Developers, and users can put specific terms to help organize our bug tracker. Unlike the Keywords field, there are no restrictions set by the bug tracker on what can go in the Whiteboard box. This being said we have some general guidelines:

    • use whiteboard status sparingly, many things can be accomplished by appropriately using version, OS, keywords, and comments
    • Whiteboard status' not listed below should be “vetted” (discussed) on the QA list before adding a new one
      • If a new whiteboard status is desired, please email the QA list and explain what purpose it would serve.

    Other Comments:

    • If the whiteboard status is a single word it is completely in lower case
    • If the whiteboard status is multiple words then the status is wimpyCaps (one run on word where each word after the first is capitalized)
    • Do NOT use commas – separate whiteboard status' with a space only
    • Whiteboard is meant to organize the bug tracker – use it wisely :)

    Complete List of Accepted Whiteboard Tags

    ODF related (should be keywords really)


    Description: a very general keyword for any kind of interoperability problem in consuming or producing ODF documents

    Use: should be obvious


    Description: is specifically for bugs about LO producing invalid or non-conforming ODF documents

    Use: if an ODF validator complains about a document that LO produced (make sure you configure the ODF validator according to the version in Tools->Options->Load/Save->General->ODF format version)

    Automatic Messages


    Description: target refers to the version(s) where a commit which fixes the problem can be expected to be seen.

    Use: Generally “target” is automatically entered when a developer commits a patch specifically to fix a bug reported on the bug tracker. Users, QA and Developer should generally not manually enter “target” into whiteboard, the only exception is when the automatic system did not tag the bug and a developer or QA member knows the exact commit which fixed the bug and what version of LibreOffice will see the patch. In these cases a QA member can mark a bug as “target:x.x.x.x” where x.x.x.x is the version(s) of LibreOffice where the commit was pushed to.



    This means that a commit which fixes the problem was committed to the, and therefore if a user or QA member tests they should not see the bug any longer.


    Description: BSA refers to “Bug Submission Assistant” and when in the whiteboard means that the bug was submitted through our bug submission assistant. For more information about BSA click here.

    Use: Always entered automatically, no need to ever manually put BSA into whiteboard.




    Description: Used in cases where a bug has been confirmed to be a regression but the regression occurred after the last commit in the latest bibisect package.

    Use: If a regression is confirmed on master or on a recent daily build then it's likely going to be too new to be bibisected. QA should still try to bibisect the bug just in case the bad commit is within the bibisect range.

    commit:commit hash

    Description: Used when the exact regression-causing commit has been found through bisection. Adding this to a report makes it easier to find duplicate regression reports and other bugs affected by the same commit.





    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:” and then version and OS (see examples above).


    Description: Used for bugs that are fixed in the master build, but aren't fixed in the Fresh or Still branches

    Use: Should be used when a bug has been found to be fixed in the current master build but not in one of our active release branches. See the documentation for Status: RESOLVED.

    Should be removed once a given bug has been fixed in all active release branches or replaced by backportDenied is it was rejected to be backported.





    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.




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

    Use: Only used for unique hardware 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 . . .). Use “filter:xxx” to specify a particular file format.


    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.

    Release Notes


    Description: To track which new features have already been recorded in a major version's release notes.

    Use : Similarly to the "target" value, the version number can be appended. QA members can mark a bug as “inReleaseNotes:x.x” where x.x is the major version of LibreOffice where the feature landed and for which the Release Notes wiki page has the feature description.




    We have a number of whiteboard status' that have either been completely retired, consolidated or changed in one way or another. The list of these retired terms can be found here: QA/Bugzilla/Fields/Whiteboard/Inactive