Get Involved/Issue Reporting
Have you found a problem with KDE Software, or a way that you think it could be improved? KDE would like to know about it! This page will give you an overview of the process of reporting a bug or making a feature request, teach you how to submit a good report, and walk you through the process of doing so using https://bugs.kde.org, KDE's Bugzilla issue tracker.
Issue reporting involves responsibility
Before you report a Bugzilla ticket, please make sure that you are:
- ...using relatively recent versions of KDE software (≤ 1 year old) or an LTS supported version
- ...willing to do whatever is necessary to get the bug to happen again (if reporting a bug)
- ...willing to correspond with KDE developers about the issue, potentially over an extended period of time
- ...prepared to gather and report a lot of additional information
- ...ready to potentially use a terminal program to execute command line debugging tools
If those points all apply to you, then we can move on! Let's see now make sure that the issue you're experiencing is something that can be reported.
Step 0: Is it a security issue?
Do not file bug reports for security issues, as this makes the vulnerability public and could expose users to exploits. Instead, send an email to [email protected]. For more information, see https://kde.org/info/security/.
Step 1: Make sure it's a valid bug or feature request
Do not file Bugzilla tickets for vague or subjective matters, support questions, or developer questions. Instead, you might try bringing up the matter on the KDE forum or another online discussion group of your choice.
Valid Bugzilla tickets describe crashes, broken functionality, anything that causes data loss, design or usability problems, translation problems, typos, and accessibility issues. Bug reports are also used for requesting new features (use the "wishlist" severity).
If any of the above describe your issue, proceed to step 2.
Step 2: Make sure it hasn't already been fixed
If you've found a real bug or want to request a new feature, you're well on your way! But wait... are you using the latest version of the program? If not, it may have already been fixed or implemented in a later release. Many Linux distros--including popular ones like Linux Mint, Debian Stable, Kubuntu, and openSUSE Leap--will intentionally hold back newer versions in the name of stability.
Option A: try the nightly Flatpak build
Most KDE projects regularly build a "nightly" version of their latest code under development, which you can install. For applications on Linux, the easiest way to try reproducing with this "bleeding edge" code is to install the nightly Flatpak of the application, which you can run independently of updating your system's KDE packages. See Guidelines_and_HOWTOs/Flatpak.
If the problem is still present in the nightly build of the software, proceed to step 3.
Option B: upgrade your KDE packages
If the software in question does not have a nightly Flatpak build, or if the issue is in Plasma rather than a self-contained app, you can try to upgrade your system packages. Here's how to do it for various distros.
Warning
- Kubuntu:
sudo add-apt-repository ppa:kubuntu-ppa/backports && sudo apt update && sudo apt upgrade
- Fedora:
sudo dnf copr enable zawertun/kde && sudo dnf upgrade --refresh
- openSUSE Leap: [insert openSUSE Leap instructions here; delete list item if it isn't possible]
If you are unable to upgrade your packages, please don't file Bugzilla issues against a version of KDE Software that's more than a year old. Many of these bug reports will be closed as already fixed, and this takes up our faithful bug triagers' valuable time!
If the problem is still present in a recent version of the software, proceed to step 3.
Step 3: Make sure you can reproduce it (bugs only)
So your issue is a real bug, and it's still present in a recent version of the software. But if it only happened once and you cannot get it to happen again no matter what you do, then there is almost no chance that it can be fixed. Please do not report bugs that you cannot reproduce.
If you can reproduce the bug, proceed to step 4.
Step 4: Log into or set up a Bugzilla account
Navigate to https://bugs.kde.org/. If you already have an account, click the "Log in" text and enter your username and password, then proceed to Step 5. Please note that https://bugs.kde.org does not use the accounts defined on identity.kde.org right now.
If this is your first time on the KDE Bugzilla, it's time to sign up for an account! Click on the "New Account" text at the top of the page. You will be prompted for your email address and can then proceed with the usual process of setting up an account. Log into your new account and proceed to step 5.
Step 5: Make sure it hasn't already been filed
First, let's make sure that this issue hasn't already been reported. Navigate to https://bugs.kde.org/query.cgi and search for a few keywords that describe your problem. For example, if the problem is that Dolphin crashes when you attempt to access a Samba share, you might search for "dolphin samba crash".
Look through the Bugzilla tickets that show up in the search results. If you find one that matches, great! Please do not intentionally open a duplicate Bugzilla ticket.
If none of the Bugzilla tickets returned by the search seem to describe your issue, proceed to step 6.
Step 6: File a high-quality Bugzilla ticket
It's time to file a new Bugzilla ticket! Click on the "New" text in the top-left corner of the screen. You will be presented with a list of products. Take your best guess for what product the ticket should belong to, and don't worry if you get it wrong. This is what KDE's bug triagers are for! Over time you'll get a feel for which products correspond to which issues.
Summary
Every Bugzilla ticket needs a good title, which goes in the "Summary" field. A good title succinctly describes the issue, can be read as a complete sentence, and avoids using charged language.
Software versions
If your issue involves a KDE app, we need to know the app version; you can find that in the Program itself, in the Help menu > About <program> window.
If you are running KDE Plasma, Open the Info Center program, click the "Copy to Clipboard" button, and paste the output here.
Steps to Reproduce
Write a detailed Steps To Reproduce section in the Bugzilla ticket. Here is an example of a perfect Steps to Reproduce section:
Steps to Reproduce:
1. Open Discover
2. Click on Applications
3. Click on the search box, type an application name (Eg. VLC) and press enter
4. Click on the icon to enter the app description
5. Click on the cross to delete the text written in the search box
6. Click on the search box in order to write another word
7. Write another app name (Eg. Chromium)
8. Press ENTER to confirm the search
9. It always crashes
Screenshots and screen recordings
If the issue involves anything visible in the program's user interface, please include screenshots--or better yet, a screen recording. Bugzilla tickets that can show an issue visually have a much higher chance of being promptly resolved.
You can press the "Print Screen" button on your keyboard to open Spectacle to take a screenshot. To take a screen recording, we recommend the SimpleScreenRecorder app (on X11) or OBS (on Wayland). Screen recordings must use the webm format and be under 4MB in size.
Use the "Add Attachment" button to attach your screenshot or screen recording. Don't post links to images hosted elsewhere, as they will eventually go stale and the images will become inaccessible.
Things to avoid
Multiple issues in a single Bugzilla ticket
A Bugzilla ticket describing multiple issues is not actionable and is likely to be closed. Each Bugzilla ticket must describe only a single issue; file multiple Bugzilla tickets to report multiple issues. If the conversation in your Bugzilla ticket derails and starts to describe multiple issues, file other Bugzilla tickets to describe them, and try to redirect the conversation back to the original issue.
Proposing a solution
The problem you're encountering is obvious to you, but it will only be equally obvious to KDE's bug triagers and developers if you describe it with detail and accuracy. If you propose an initial solution without adequately describing the problem, they'll have a hard time helping you because they won't be able to figure out what's actually going on. Even if your proposed solution makes sense, it will be difficult to verify this without knowing what problem it would be solving. Always describe the problem itself, rather than proposing a solution to it.
Crash report without a backtrace
If you use the DrKonqi crash reporting assistant to report the bug, this will happen automatically. If not, or if the issue is a hang rather than a crash, you must include a backtrace yourself. Do not submit a Bugzilla ticket about a crash or a hang if you are unable to include a backtrace, as it is not actionable and will be closed.
Next steps
Thanks for the Bugzilla ticket! You just helped make KDE software a little bit better.
Monitor the email address that you use for your Bugzilla account. You will receive an email if a KDE bug triager or developer needs to contact you for any reason.
Nevertheless, since KDE is a mostly volunteer project, you may not receive an immediate response. This is normal and should not be taken to mean that your Bugzilla ticket is not valued! Rather, it is a reflection of KDE's limited issue triaging resources. If you would like to help alleviate this situation, becoming a KDE bug triager is one of the absolute best ways to contribute!
Issue tracker etiquette
Using an issue tracker may be an unfamiliar experience. Here are some tips to help your interpersonal interactions be as smooth as possible:
Remember your manners
Filing a Bugzilla ticket is akin to mildly criticizing someone's work--work that was likely done for free, on personal time, as a labor of love. Please respect the developers by being polite and patient. Think to yourself, "what would my mother say if she read my words here?"
More practically, acting rude, annoying, or argumentative is counterproductive because volunteer developers will avoid fixing issues that require them to interact with unpleasant people. Would you do unpaid work for a stranger who is annoying or insulting you? Probably not.
Arguing almost always gets nowhere, and both parties simply become more entrenched in their existing opinions. If you feel resistance building, take a few hours or a day to cool down, and then try another approach later.
Have realistic expectations
Most developers working on KDE software are unpaid volunteers. Those who are paid to work on KDE software are typically paid by their employer to work on specific areas of interest to their employer, not general user-reported issues.
As a result, there are extremely limited developer resources for fixing issues reported by users or even noticing and replying to them. Most of the time there will be a lot of waiting involved, and possibly a lot of discussion too. This is normal. If a Bugzilla ticket is going unaddressed, this is probably a sign that KDE's development resources are stretched thin. It is not helpful or effective to poke the developers by posting things like "Me too!" or "I have this bug as well!" or "Why doesn't anyone want to fix these very important issues? Doesn't KDE care?????" We definitely care, but we don't always have the resources to fix everything quickly!
Consider trying to fix the issue yourself, or donate money to KDE so that there are eventually enough resources to hire full-time developers to fix user-submitted bug issues.
Also, Bugzilla ticket are not assigned to specific people; anyone can fix a Bugzilla ticket, respond to the reporter, engage in discussion, and so on.
Have a thick skin
Sometimes your Bugzilla ticket will get closed without the resolution you're hoping for. This feels disappointing, but it's not the end of the world, so try not to take it personally. The project is larger than any one of us.
Submit patches using GitLab, not the issue tracker
A Bugzilla ticket with a patch is an incredible blessing. But patches attached to Bugzilla ticket tend to get missed and become stale over time, which is a real shame. Instead of attaching your patch to the Bugzilla ticket, please submit it as a merge request using GitLab instead, and paste a link to the merge request in the Bugzilla ticket.
Understand what the resolution statuses mean
Some of them can sound a little harsh, but again, don't take it personally. These words are just descriptions of the different statuses for the Bugzilla ticket itself:
- RESOLVED does not necessarily mean that the issue has been fixed for you, just that the Bugzilla ticket itself is no longer considered actionable by the developers. For example, a Bugzilla ticket may be marked as RESOLVED UPSTREAM if it's traced to a Qt issue, even if the Qt issue has not yet been fixed, or the version of Qt that fixes the bug is not yet released or available in your distro. Similarly, a ticket may be marked as RESOLVED DOWNSTREAM if the problem is caused a 3rd-party software, even if that issue has not yet been fixed or even tracked by a bug report in the 3rd-party app's bug tracker. These are normal outcomes; KDE's issue tracker can only be used to track issues in KDE's own software.
- RESOLVED INTENTIONAL does not mean "shut up and go away, we don't care!" What is much more likely is that the issue is not actually considered a real issue, or cannot be fixed without a reasonable amount of engineering effort.
- RESOLVED NOT A BUG does not mean, "you're an idiot who doesn't know how to use issue trackers!" Rather, it means that the Bugzilla ticket itself is describing something that isn't a bug or feature request, or is something that KDE developers can't fix.