LibreOffice Bugzilla Bug Reporting Protocols

This article provides a comprehensive overview of the bug reporting protocols established on the LibreOffice Bugzilla platform. It outlines the standard procedures required for submitting high-quality defect reports, including pre-submission checks, mandatory submission fields, issue classification, lifecycle statuses, and specialized reporting practices like regression tagging and crash log submission.

Pre-Submission Verification

Before submitting a new report, users and Quality Assurance (QA) contributors must follow standard verification steps:

• Search for Duplicates: Search the Bugzilla database using keywords, error messages, or component names to ensure the issue has not already been reported.
• Test with Clean Profiles: Test the issue in LibreOffice Safe Mode (Help > Restart in Safe Mode) to rule out corrupted user profiles or misconfigured extensions.
• Verify on the Latest Version: Check if the defect persists in the latest stable (“Fresh”) release, the latest development build, or the latest pre-release build.

Essential Information Required in Bug Reports

When opening a new bug ticket, specific technical details must be provided to ensure developers and QA volunteers can reproduce the issue:

1. Summary: A concise, descriptive title outlining the exact failure and the affected module.
2. Environment Details: The exact operating system, architecture (32-bit/64-bit), and complete LibreOffice version details, which can be copied directly from Help > About LibreOffice.
3. Step-by-Step Instructions: A numbered, precise list of steps to reproduce the behavior from a blank document or fresh launch.
4. Expected vs. Actual Behavior: A clear statement describing what should have happened versus what actually occurred.
5. Attachments: Minimal sample files that trigger the bug, screenshots (where relevant for visual glitches), and stack traces for crashes.

Severity and Priority Classifications

LibreOffice Bugzilla strictly separates user-assigned severity from developer-assigned priority:

• Severity: Describes the impact on the user. Reporters may set this to:
  • Blocker: Causes crashes, data loss, or blocks basic functionality.
  • Critical: Major functionality is broken with no workaround.
  • Major: Major functionality is broken, but a workaround exists.
  • Normal: Default level for most regular bugs.
  • Minor / Trivial: Minor functional issues, cosmetic defects, or UI typos.
  • Enhancement: Requests for new features or functionality improvements.
• Priority: Dictates the scheduling order for developer resolution. This field is managed exclusively by the QA team and core developers.

The Bug Lifecycle and Status Protocols

Bug reports move through distinct statuses during their lifecycle:

• UNCONFIRMED: The default initial state for reports submitted by general users.
• NEW: Assigned by QA triagers once the issue is reproduced and validated with proper information.
• ASSIGNED: A developer has taken ownership of the bug and is actively working on a fix.
• NEEDINFO: Additional details, test files, or clarification are requested from the reporter.
• RESOLVED: The issue is addressed. Common resolution resolutions include FIXED, DUPLICATE, NOTABUG, WONTFIX, or WORKSFORME.
• VERIFIED: QA or the original reporter confirms that the fix works in a newer build.
• CLOSED: The final administrative state confirming the bug lifecycle is complete.

Specialized Protocols

LibreOffice incorporates specialized reporting workflows for complex defects:

• Regressions: If a feature worked in an older version but fails in a newer version, the report is tagged with the regression keyword. Advanced contributors may perform a “bibisect” to identify the exact commit that introduced the regression.
• Crashes and Freezes: When reporting unexpected termination, contributors are expected to attach a debugger backtrace (such as from GDB on Linux/macOS or WinDbg on Windows) or provide a link to the LibreOffice Crash Report server using the generated Crash ID.