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

Real issues involve any of the following:

Crashes
Broken functionality
Anything that causes data loss
Design issues, such as faulty paddings/margins, misplaced content, lack of consistency with the rest of the desktop, incorrect icon/image rendering, or other user interface anomalies
Translation problems, where certain words or expressions are inappropriate for a given context, or a part of a program that was not properly translated or is lacking translation
Typographic errors (typos), unclear instructions or general communication, inappropriate grammar or style, or not conveying a program's functionality correctly
Usability issues, such as inappropriate default window sizes, excessive or non-optimal amount of clicks to achieve a task, and others
Accessibility issues, such as text or software itself that cannot be used with a text-to-speech interface or screen reader
Request for missing features or ideas about how something that's already working could be further improved

If your issue is on this list, proceed onto step 2.

By contrast, here are some examples of issues that are almost never real issues:

Vague and subjective matters of aesthetics or personal preference (e.g. "The program is ugly")
Design choices too broad to be changed by a Bugzilla ticket (e.g. "The program should work more like this other program that I'm used to")
Anything caused by user or vendor configuration choices (e.g. "The program disappeared after I did a system update")
Support questions ("How do I change such-and-such behavior of the program?")
Development assistance requests ("Can you help me compile the program?")

Do not file Bugzilla tickets 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 valid, but require some more investigation:

"The program is really slow" (It could be a bug in the software, or it could be an issue with your computer or its configuration)
"Some of the program's icons are inconsistent" (If you're using a 3rd-party icon theme, that could be causing the problem)
"The program did something unexpected in response to an action that I took" (this could be a bug or a usability issue, or it could just be that the program's operation is unfamiliar to you)
"The label for one of the program's user interface controls doesn't clearly indicate what it does" (It could be a badly-worded or badly-translated piece of text, or it could be a 3rd-party widget theme mangling the user interface)

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.

Step 2: Make sure it hasn't already been fixed

If you've found a real bug or want to report a valid feature request, 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. 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 new features! 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: upgrade your KDE packages

You should first upgrade your packages. Here's how to do it for various distros.

Warning

Due to the nature of package dependencies, this will upgrade the entire KDE software stack. Do not proceed unless you are okay with this.

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.

Option B: try a developer Flatpak build

Many 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 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 file a duplicate.

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. Keep in mind the following guidelines:

One issue per 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 ticket to report multiple issues. If the conversation in your Bugzilla ticket derails and starts to describe multiple issues, file other Bugzilla ticket to describe them, and try to redirect the conversation back to the original issue.

Describe the problem instead of 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 will 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 actually makes sense, it will be difficult to verify this without knowing what problem it would be solving. Always describe the problem itself.

Crash reports must include backtraces

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.

In your Bugzilla ticket, include the following information:

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. Examples of good titles:

"Discover 5.12 crashes when I navigate to an app page and search twice"
"Gwenview's «Exit Full Screen» button becomes inaccessible when the sidebar is opened"
"KIO Local copy performance with 50,000 small files in Dolphin is 4.5x slower than using cp"

And here are the kinds of titles that you should avoid:

"App always crashes"
"HELP HELP HELP CANNOT ACCESS MY FILES ANYMORE THX"
"Old version worked much better; new version is terrible"
"Cannot do anything"
"bug"

Software versions

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 Bugzilla ticket:

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

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 Bugzilla ticket 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.

Additional information

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!

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 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!

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 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. Think about it: Would you do unpaid work for a stranger who you felt had insulted you?

Avoid arguments

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. Nevertheless, sometimes KDE's developers will have a Bugzilla ticket resolved quickly, 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 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 personal. The project is larger than any one of us.

Don't confirm your own issue

Do not set your own Bugzilla ticket to the CONFIRMED status. This status exists for KDE bug triagers and developers.

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.

Why don't you use GitLab issues?

See Why not GitLab Issues?.