QA/Bugzilla/Fields/Whiteboard

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


    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.

    Markup

    • Use wimpyCapsWikipedia 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!

    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