Bug Reporting Guidelines
GNOME uses GitLab to manage bug reports and feature requests. It helps developers keep track of what is broken and who might fix it. Users can help our effort by making their bug reports clear and specific. The better your bug report, the easier it is to identify the cause, and fix the bug.
To write a good bug report:
Do give clear step by step instructions on how to reproduce the problem.
Do write a summary that is specific enough to distinguish the bug from most others. Good: "Network Setup Tool hangs when verifying DHCP server." Bad: "Setup Tools Crash."
Do tell us the exact name and version of all relevant software, including your distribution and operating system. For example:"Nautilus-sendto 0.10 won't work with bluez-gnome 0.6 from my Mandriva 2008 beta system." Don't say "I'm using Linux, and bluetooth crashes."
If it is about a crash: do include a stack trace and any error messages or console output the application gave. Please don't attach core files. Do not attach screenshots unless a screenshot demonstrates a specific user interface problem that is really hard to explain in words.
- A good bug report is:
Reproducible: If a developer cannot see the bug or cannot reproduce, the bug report might get closed as unreproducible. Provide step-by-step instructions for reproducing the bug, so someone else is able to find and work on it.
Specific: Try and figure out exactly what causes the crash. If you find an email that crashes Evolution, good. If you find what parts of the message make things go wrong, even better.
Unique: Before you report a bug, try to make sure it hasn't been reported before by taking a look at existing bug reports. If you have new information about an existing bug, please post a comment on the existing bug report.
Current. Before filing a bug, make sure you run the latest version of the program. That will minimize the chance of reporting a bug that has already been fixed.
GitLab for general information on Gitlab, for example creating an account