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 bug reporting process, teach you how to submit a good bug, and walk you through the process of doing so.
Before you report a bug, please make sure that you are:
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 really a bug.
Real bugs involve any of the following:
If your issue is on this list, proceed onto step 2.
By contrast, here are some examples of issues that are almost never real bugs:
Do not file bug reports for these kinds of issues. Instead, you might try bringing up the matter on the KDE forum or another online discussion group of your choice.
Here are examples of issues that may be real bugs, but require some more investigation:
If your issue is on this list, proceed to Step 2, but be prepared for the issue to be caused by configuration or hardware issues, or simply be an example of unfamiliar behavior.
If you've found a real bug, 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 in a later release. For example, if you are experiencing an issue with Dolphin 16.04, but the current version of Dolphin is 18.04, then you're missing out on two years worth of bugfixes and improvements! 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. But this won't help you if you're encountering a bug!
You should first upgrade your packages. Here's how to do it for various distros.
|Due to the nature of package dependencies, this will upgrade the entire KDE software stack. Do not proceed unless you are okay with this.|
sudo add-apt-repository ppa:kubuntu-ppa/backports && sudo apt update && sudo apt upgrade
If you are unable to upgrade your packages, please don't file bugs 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.
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 issue, proceed to step 4.
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 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.
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 bugs that show up in the search results. If you find one that matches, great! Please do not file a duplicate.
If none of the bugs seems to describe your issue, proceed to step 6.
It's time to file a new bug report! 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 bug report should belong to, and don't worry if you get it wrong. This is what KDE's bug screeners are for! Over time you'll get a feel for which products correspond to which issues.
Only report a single issue per bug report. A bug report describing multiple issues is not actionable and is likely to be closed. Each bug report must describe only a single issue; file multiple bug reports to report multiple issues. If the conversation in your bug report derails and starts to describe multiple issues, file other bugs to describe them, and try to redirect the conversation back to the original issue.
A bug report describing a crash or a hang must include 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 bug about a crash or a hang if you are unable to include a backtrace, as it is not actionable and will be closed.
In your bug report, include the following information:
Every bug 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. Examples of good titles:
And here are the kinds of titles that you should avoid:
First, find out what versions of various pieces of KDE software you're running. Open the Info Center program (which is installed in all KDE Plasma environments) and write the following in the top of the bug report:
Distro and version (e.g Kubuntu 17.10)
Qt version (e.g. Qt 5.9.1)
KDE Plasma version (e.g. Plasma 5.12)
KDE Frameworks version (e.g. Frameworks 5.42)
If your issue involves a KDE app, we need to know the app version, too. You can find that in the Program itself, in the Help menu > About <program> window
Write a detailed Steps To Reproduce section in the bug report. 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
If the bug involves anything visible in the program's user interface, it is highly recommended to include screenshots--or better yet, a screen recording. Bugzilla tickets that can show the issue visually have a much higher chance of being promptly resolved.
You can use Spectacle to take a screenshot. By default, it will open in response to the "Print Screen" button on your keyboard. To take a screen recording, we recommend the SimpleScreenRecorder app. 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.
If there is any additional information or attachments that you feel would help KDE developers reproduce, investigate, or fix the issue, please mention it here!
Thanks for the bug report! 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 bug report is not valued! Rather, it is a reflection of KDE's limited bug 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!
Using a bug tracker may be an unfamiliar experience. Here are some tips to help your interpersonal interactions be as smooth as possible:
Filing a bug is akin to 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 not using rudeness or insults; think to yourself, "what would my mother say if she read this?" In addition to being bad manners, it's counterproductive because you will provoke defensiveness and spark arguments, and developers will not feel like doing the work that you're requesting. Would you do unpaid work for a stranger who you felt had insulted you?
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.
Bugs are not assigned to specific people; anyone can fix a bug, respond to the bug reporter, engage in discussion, and so on. Sometimes KDE developers will have a bug fixed in under 24 hours, which is amazing. However, most of the time there will be a lot of waiting involved, and possibly a lot of discussion too. This is normal. If a bug 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! You might consider trying to help fix it yourself!
Sometimes your bug report will get closed without the resolution you're hoping for. This feels disappointing, but it's not personal. The project is larger than any one of us.
Do not set your own bug to the CONFIRMED status. This status exists for KDE bug triagers and developers.
A bug report with a patch is an incredible blessing. But patches attached to bug reports tend to get missed and become stale over time, which is a real shame. Instead of attaching your patch to the bug report, please submit it using Phabricator instead, and paste a link to your Phabricator revision in the bug report.
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 bug report itself: