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 or feature request:

  • Do give clear step by step instructions on how to reproduce the problem.

  • Do write a specific summary which allows to distinguish the bug from most others. Good: "Network Setup Tool hangs when verifying DHCP server." Bad: "Setup Tools Crash."

  • Do tell the exact name and versions of all relevant software, including your distribution and operating system. For example: "I am using nautilus version 0.10.4 and bluez 1.8.3 on FooBar Linux version 13.02." Don't say "I'm using Linux, and bluetooth crashes."

  • Do use a recent software version. If your version is more than a year old and you cannot first upgrade to a recent version, then please report the problem to your distribution's issue tracker instead.

  • If it is about a crash: do include a '''stack trace''' which has '''debug symbols'''. It does not have debug symbols by default! Include any error messages or console output the application gave. Please do not 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 reproduce the problem, the bug report might get closed as unreproducible. Provide step-by-step instructions for reproducing the bug which leave no room for interpretation, so someone else is able to find the problem and work on it.

    • Specific: Only report one problem or feature request per one ticket. Try and figure out exactly what causes the problem. If you find an email that crashes the email client, 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.

See Also

  • GitLab for general information on Gitlab, for example creating an account

GettingInTouch/BugReportingGuidelines (last edited 2022-06-14 13:30:29 by AndreKlapper)