Guidelines for public and private sector deployments
The majority of bug report analysis (triaging) for LibreOffice is done by volunteers. Thus, if you get paid to manage a LibreOffice deployment, you should fully triage the reports you create. This is the only sustainable and fair way to collaborate.
If you are just starting out, go and read the article about getting involved first. Come and talk with us on IRC connect via webchat and tell us about your deployment and plans on the QA mailing list.
TDF's QA engineer and the rest of the team will teach you everything you need to know. Voice call sessions are possible, if you find them to be an efficient way of learning.
Special permission to self-confirm
In the case that you process user reports from your deployment and confirm them yourself, setting the reports to NEW in TDF's Bugzilla immediately makes a lot of sense. However, the QA team first has to trust you to do a good job with the triaging. You should be familiar with the full triaging process, including regression testing. Bibisecting is not a requirement, but is very welcome.
An experienced member of the QA team may interview you before you are given permission to start self-confirming your reports.
If you suspect an issue is linked to your specific deployment setup, you should test it in a different environment. An ideal testing routine would include different operating systems on real hardware or virtual machines. It is very valuable to know whether an issue only happens under a certain operating system or uniformly across all the major ones (Win/macOS/Linux).
The following deployments have received the blessing of the QA team to self-confirm their reports when appropriate:
- The City of Munich in Germany has deployed LibreOffice on more than 20,000 clients running in a mixed Linux/Windows environment, using German as the UI language. Over the years, the City of Munich has employed several developers contributing to both fundamental and user-facing improvements in LibreOffice.