Get Involved/Issue Reporting: Difference between revisions

From KDE Community Wiki
m (fix big margin)
 
(33 intermediate revisions by 12 users not shown)
Line 6: Line 6:
* ...using relatively recent versions of KDE software (≤ 1 year old) or an LTS supported version
* ...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 do whatever is necessary to get the bug to happen again (if reporting a bug)
* ...willing to preserve the buggy environment/situation for testing purposes, and not do anything that destroys your ability to reproduce the bug such as reinstalling your OS or deleting all your settings
* ...willing to correspond with KDE developers about the issue, potentially over an extended period of time
* ...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
* ...prepared to gather and report a lot of additional information
* ...ready to potentially use a terminal program to execute command line debugging tools
* ...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.
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.
Line 16: Line 18:


= Step 1: Make sure it's a valid bug or feature request =
= Step 1: Make sure it's a valid bug or feature request =
Real issues involve any of the following:
Do not file Bugzilla tickets for vague or subjective matters, support questions, developer questions, or overbroad requests for giant changes to everything or new features with a massive scope. Instead, you might try bringing up the matter on the [https://forum.kde.org/ KDE forum] or another online discussion group of your choice.
* 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'''.
Valid Bugzilla tickets describe crashes, broken functionality, anything that causes data loss, specific design or usability problems, translation problems, typos, and accessibility issues. Bug reports are also used for requesting new features (use the "wishlist" severity).


By contrast, here are some examples of issues that are almost never real issues:
If any of the above describe your issue, '''proceed to step 2'''.
* 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 [https://forum.kde.org/ KDE forum] or another online discussion group of your choice.
= 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.


Here are examples of issues that ''may'' be valid, but require some more investigation:
If you are using one of these Linux distros, please try a newer version of the KDE software in question first, using one of the following methods:
* "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.
== 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]].


= Step 2: Make sure it hasn't already been fixed =
If the problem is still present in the nightly build of the software, '''proceed to step 3'''.
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 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.
 
Some distros like Fedora and OpenSUSE Leap  


You should first upgrade your packages. Here's how to do it for various distros.
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.}}
{{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: <pre>sudo add-apt-repository ppa:kubuntu-ppa/backports && sudo apt update && sudo apt upgrade</pre>
* Kubuntu: <pre>sudo add-apt-repository ppa:kubuntu-ppa/backports && sudo apt update && sudo apt upgrade</pre>
* Fedora: [insert openSUSE Leap instructions here; delete list item if it isn't possible]
* OpenSUSE: check the [https://en.opensuse.org/SDB:KDE_repositories official documentation]
* openSUSE Leap: [insert openSUSE Leap instructions here; delete list item if it isn't possible]
* Fedora: with the exception of major KDE releases, Fedora already ships KDE updates pretty quickly.


If you are unable to upgrade your packages, '''please don't file Bugzilla tickets 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 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'''.
If the problem is still present in a recent version of the software, '''proceed to step 3'''.
Line 72: Line 62:
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".
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'''.
Look through the Bugzilla tickets that show up in the search results. If you find one that matches, feel free to subscribe yourself to it simply by pressing the "Save Changes" button. '''Please do not intentionally open a duplicate Bugzilla ticket or leave a comment saying "I'm affected too."'''.
 
If you find an issue that's marked as RESOLVED FIXED that seems to describe your issue, '''do not re-open it or post a new comment in it.''' Issues that look alike often have subtly different root causes that need to be fixed separately. Instead, submit a new bug report and mention the one you found that's marked as already fixed.


If none of the Bugzilla tickets returned by the search seem to describe your issue, '''proceed to step 6'''.
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 =
= 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:
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.
 
=== 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, [[Guidelines and HOWTOs/Debugging/How to create useful crash reports|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.
 
<br/> <br/>
In your Bugzilla ticket, include the following information:


=== Summary ===
=== 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:
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.
* "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 ===
=== 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:
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.
<blockquote>
Distro and version (e.g Kubuntu 17.10)<br />
Qt version (e.g. Qt 5.9.1) <br />
KDE Plasma version (e.g. Plasma 5.12)<br />
KDE Frameworks version (e.g. Frameworks 5.42)<br />
</blockquote>


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
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 ===
=== Steps to Reproduce ===
Line 131: Line 95:


=== Screenshots and screen recordings ===
=== 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.
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 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.
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.
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 ===
=== Things to avoid ===
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!
 
==== 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, [[Guidelines and HOWTOs/Debugging/How to create useful crash reports|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.




Line 146: Line 118:
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.
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, [[Guidelines and HOWTOs/Bug triaging | becoming a KDE bug triager]] is one of the absolute best ways to contribute!
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, [[Guidelines and HOWTOs/Bug triaging | becoming a KDE bug triager]] is one of the absolute best ways to contribute!


= Issue tracker etiquette =
= Issue tracker etiquette =
Line 152: Line 124:


=== Remember your manners ===
=== 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?
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.


=== 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.
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 ===
=== Have realistic expectations ===
Bugzilla ticket are not assigned to specific people; anyone can fix a bug, respond to the Bugzilla ticket reporter, engage in discussion, and so on. Sometimes KDE developers will have a Bugzilla ticket resolved 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 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! You might consider trying to help [[Get Involved/development|fix it yourself]]!
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 [[Get Involved/development|fix the issue yourself]], or [https://kde.org/community/donations/ donate money to KDE] so that there are eventually enough resources to hire full-time developers to fix user-submitted bug issues.
 
Also, Bugzilla tickets 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 ===
=== 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.
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.


=== Don't confirm your own issue ===
=== Submit patches using GitLab, not the issue tracker ===
Do not set your own Bugzilla ticket to the CONFIRMED status. This status exists for KDE bug triagers and developers.
A Bugzilla ticket with a patch is an incredible blessing. But patches attached to Bugzilla tickets 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 [[Infrastructure/GitLab|GitLab]] instead, and paste a link to the merge request in the Bugzilla ticket.


=== Submit patches using Phabricator, not the issue tracker ===
=== Why don't you use GitLab issues? ===
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 using [[Infrastructure/Phabricator|Phabricator]] instead, and paste a link to your Phabricator revision in the Bugzilla ticket.
See [[Get Involved/Issue Reporting/Why not GitLab Issues|Why not GitLab Issues?]].


=== Understand what the resolution statuses mean ===
= 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:
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. In particular, 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. Specifically:
* 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. This is a normal outcome on issue trackers; if you want the issue to be fixed for yourself faster, comment in the upstream bug report, or ask your distro to backport the fix for you.
* '''RESOLVED FIXED''' means the issue has been fixed by KDE--even if the version that contains the fix has not been released yet, or if you are not yet using the version that contains this fix. This might be because you have not yet upgraded your system, or because your distribution does not offer recent enough versions of KDE software, which is often the case with LTS releases. You can see the earliest version of the KDE software containing the fix in the "Version Fixed In" field. If you find that your distribution does not offer recent enough versions of KDE software for important bug fixes, you might want to consider switching to a different distribution that's closer to the release schedule of the software it ships. 
* 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 WORKSFORME''' means the bug can no longer be reproduced by the original poster or any of the developers--even if it is not clear what fixed the issue for them. 
* 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.
* '''RESOLVED DUPLICATE''' means  this particular bug report is no longer needed because the same issue is already tracked elsewhere--even if the issue in question has not yet been fixed. 
* '''RESOLVED UPSTREAM''' means the issue is not caused by any KDE software, but rather in some upstream software that KDE software depends on, such as Qt or another software library--even if the issue has not yet been fixed in that upstream software, or if the version of it that fixes the bug is not yet released or available in your distro.
* '''RESOLVED DOWNSTREAM''' means the issue is not caused by any KDE software, but rather somewhere downstream in your distro or 3rd-party content--even if that issue has not yet been fixed in the downstream software, or if the version of it that fixes the bug is not yet released or available in your distro.
* '''RESOLVED INTENTIONAL''' means the issue is not actually considered a real issue, or describes something that was designed this way intentionally, or the issue cannot be fixed without an unreasonable amount of engineering effort, or it's a feature request that doesn't match the intended scope or design of the software.
* '''RESOLVED NOT A BUG''' means the Bugzilla ticket itself is describing something that isn't a valid bug or feature request, which should be communicated somewhere else.
* '''RESOLVED UNMAINTAINED''' means the version of the software that the issue was reported against is no longer receiving updates and is therefore not eligible for support by KDE on the bug tracker. Consider upgrading to a newer version if possible.

Latest revision as of 17:51, 10 November 2024

Help Konqi catch some bugs!

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 preserve the buggy environment/situation for testing purposes, and not do anything that destroys your ability to reproduce the bug such as reinstalling your OS or deleting all your settings
  • ...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, developer questions, or overbroad requests for giant changes to everything or new features with a massive scope. 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, specific 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.

If you are using one of these Linux distros, please try a newer version of the KDE software in question first, using one of the following methods:

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.

Some distros like Fedora and OpenSUSE Leap

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
  • OpenSUSE: check the official documentation
  • Fedora: with the exception of major KDE releases, Fedora already ships KDE updates pretty quickly.

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, feel free to subscribe yourself to it simply by pressing the "Save Changes" button. Please do not intentionally open a duplicate Bugzilla ticket or leave a comment saying "I'm affected too.".

If you find an issue that's marked as RESOLVED FIXED that seems to describe your issue, do not re-open it or post a new comment in it. Issues that look alike often have subtly different root causes that need to be fixed separately. Instead, submit a new bug report and mention the one you found that's marked as already fixed.

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 tickets 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 tickets 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.

Why don't you use GitLab issues?

See Why not GitLab Issues?.

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. In particular, 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. Specifically:

  • RESOLVED FIXED means the issue has been fixed by KDE--even if the version that contains the fix has not been released yet, or if you are not yet using the version that contains this fix. This might be because you have not yet upgraded your system, or because your distribution does not offer recent enough versions of KDE software, which is often the case with LTS releases. You can see the earliest version of the KDE software containing the fix in the "Version Fixed In" field. If you find that your distribution does not offer recent enough versions of KDE software for important bug fixes, you might want to consider switching to a different distribution that's closer to the release schedule of the software it ships.
  • RESOLVED WORKSFORME means the bug can no longer be reproduced by the original poster or any of the developers--even if it is not clear what fixed the issue for them.
  • RESOLVED DUPLICATE means this particular bug report is no longer needed because the same issue is already tracked elsewhere--even if the issue in question has not yet been fixed.
  • RESOLVED UPSTREAM means the issue is not caused by any KDE software, but rather in some upstream software that KDE software depends on, such as Qt or another software library--even if the issue has not yet been fixed in that upstream software, or if the version of it that fixes the bug is not yet released or available in your distro.
  • RESOLVED DOWNSTREAM means the issue is not caused by any KDE software, but rather somewhere downstream in your distro or 3rd-party content--even if that issue has not yet been fixed in the downstream software, or if the version of it that fixes the bug is not yet released or available in your distro.
  • RESOLVED INTENTIONAL means the issue is not actually considered a real issue, or describes something that was designed this way intentionally, or the issue cannot be fixed without an unreasonable amount of engineering effort, or it's a feature request that doesn't match the intended scope or design of the software.
  • RESOLVED NOT A BUG means the Bugzilla ticket itself is describing something that isn't a valid bug or feature request, which should be communicated somewhere else.
  • RESOLVED UNMAINTAINED means the version of the software that the issue was reported against is no longer receiving updates and is therefore not eligible for support by KDE on the bug tracker. Consider upgrading to a newer version if possible.