Guidelines and HOWTOs/Bug triaging: Difference between revisions

From KDE Community Wiki
m ('neer' changed to 'newer')
No edit summary
 
(30 intermediate revisions by 11 users not shown)
Line 1: Line 1:
[[File:Mascot konqi-support-bughunt.png|thumbnail|right|Help [[Konqi]] catch some bugs!]]
[[File:Mascot konqi-support-bughunt.png|thumbnail|right|Help [[Konqi]] catch some bugs!]]
The '''KDE Bugsquad''' keeps track of incoming bugs in KDE software, and goes through old bugs. We verify that a bug exists, whether it is reproducible, and that the reporter has given enough information. '''Our goal is to save developers from doing this, which helps them fix bugs more quickly and do more work on KDE software.'''
KDE's bug triagers go through new and old bug reports to make sure they're actionable for developers. We verify that a bug exists, whether it is reproducible, and that the reporter has provided enough information for developers to action it. '''Our goal is to save developers from this task, which helps them fix bugs more quickly and do more work on KDE software.'''


Getting involved in the Bugsquad is a good place to start. An existing member will help you out and mentor you. One of the great things about the Bugsquad and bug triaging is that '''you do not need any programming knowledge!''' That said, experience has shown that members of this team learn a lot about KDE and Qt programming during the course of dealing with bug reports, and many move on to developing the software itself. If you are just starting to learn programming, bug triaging is a great way to gain familiarity with the components and give practical support to the KDE community.
One of the great things about bug triaging is that '''you don't need any programming knowledge''', only basic familiarity with KDE software and a rough overview of how the Linux software stack is arranged (e.g. Plasma on top, Qt below it, various middleware libraries below Qt, and the kernel at the bottom).


For live chat, we have the '''#kde-bugs''' [[Internet_Relay_Chat|IRC channel]] on [https://freenode.net/ Freenode]. Please feel free to stop by! You can also connect via [https://matrix.org/ Matrix] if you prefer.
That said, experience has shown that members of this team learn a lot about KDE and Qt programming during the course of dealing with bug reports, and many move on to developing the software itself. If you're just starting to learn programming, bug triaging is a great way to gain familiarity with the technical details of KDE's software architecture and provide practical support to the KDE community.


To join the Bugsquad, [https://phabricator.kde.org/project/update/290/join/ become a member] of our [https://phabricator.kde.org/project/profile/290/ project on Phabricator]. We organize Bug Days, where we focus on a specific product, with the goal of reviewing all open bugs by the end of the day. These meetings occur primarily on #kde-bugs.
When you start bug triaging, an existing member can help you out as a mentor. Just stop by the [https://webchat.kde.org/#/room/#kde-bugs:kde.org KDE Bugs Matrix group] and introduce yourself!


We have a [https://phabricator.kde.org/calendar/query/Tp0Fc0J7sB6v/ Bugsquad calendar] you can view, or export as ICS to your calendar of choice. The calendar lists all of the upcoming Bug Days and what product we will be focusing on. These days are great times to get involved and ask questions!
== Getting started ==
=== General considerations ===
* '''Be polite.''' Bug triagers are the face of KDE. Be nice to bug reporters, even if they aren't nice to you! You have an opportunity to showcase the best of the KDE community, and turn skeptics into fans. Being nice is more impactful than being right.
* '''Explain your decisions.''' It can be very frustrating for a bug reporter if their report is suddenly closed without any reason given. Especially when you close a bug report, write why you think your action is the correct one, and don't establish your opinion as the all-ruling fact. Some canned responses and explanations that have been shown to work well can be found at https://invent.kde.org/ngraham/canned-responses.
* '''Don't be afraid to make mistakes.''' Everybody makes mistakes, especially when starting out with bug triaging.
* KDE uses the Bugzilla bug tracker system. If you are not familiar with it, you may find this [[Bugsquad/Quick Introduction to Bugzilla|quick Introduction to Bugzilla]] useful.
 
=== System Setup ===
It's very important to be using the latest versions of KDE software. In general, only the latest version is supported, and it's common for people to report bugs against old versions, so you need to be able to identify this situation.
 
It's highly recommended to use a rolling release or semi-rolling distro, such as Arch or an Arch derivative, KDE Neon, Fedora KDE, or openSUSE Tumbleweed. Ideally you'll be daily-driving such a distro, but if not, using it in a VM for bug triage purposes is better than nothing.


= General considerations =
Slow discrete release distros like Ubuntu, Debian, and openSUSE Leap are not recommended.
* '''Be polite.''' Bug triagers are the face of KDE. Be nice to bug reporters, even if they aren't nice to you! You have an opportunity to showcase the best of the KDE community, and turn skeptics into fans. Being nice is more impactful than being right.
* '''Explain your decisions.''' It can be very frustrating for a bug reporter if his/her report is suddenly closed without any reason. Write why you think that your action is the correct one, and don't establish your opinion as the all-ruling fact.
* '''Don't be afraid to make mistakes.''' Everybody does make mistakes, especially when starting out with bug triaging.
* KDE uses the Bugzilla bug tracker system. If you are not familiar with it, you may find this [[Bugsquad/Quick Introduction to Bugzilla|quick Introduction to Bugzilla]] useful.
* The [https://addons.mozilla.org/en-US/firefox/addon/bugzillajs/ BugzillaJS add-on for Firefox] is highly recommended, as it greatly improves the user experience.


= Decide what to work on =
=== Decide what to work on ===
=== All bugs filed recently ===
==== All bugs filed recently ====
* All the bugs ('''any type''') reported [https://bugs.kde.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=UNCONFIRMED&bugidtype=include&chfield=%5BBug+creation%5D&chfieldfrom=1d&chfieldto=Now&bug_file_loc=&cmdtype=doit today] or the [https://bugs.kde.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=UNCONFIRMED&bugidtype=include&chfield=%5BBug+creation%5D&chfieldfrom=7d&chfieldto=Now&bug_file_loc=&cmdtype=doit last week]
Going through all bugs submitted recently in an organized manner is hugely impactful. Here are some links to Bugzilla searches that will update automatically over time:
* All the '''crashes''' reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]
* All bugs and feature requests reported [https://bugs.kde.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=UNCONFIRMED&bugidtype=include&chfield=%5BBug+creation%5D&chfieldfrom=1d&chfieldto=Now&bug_file_loc=&cmdtype=doit today] or in the [https://bugs.kde.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=UNCONFIRMED&bugidtype=include&chfield=%5BBug+creation%5D&chfieldfrom=7d&chfieldto=Now&bug_file_loc=&cmdtype=doit last week]
* All the '''normal bugs''' reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]
* All Plasma bugs and feature requests reported [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&chfield=%5BBug%20creation%5D&chfieldfrom=1d&chfieldto=Now&classification=Plasma&list_id=2385376&query_format=advanced today] or in the [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&chfield=%5BBug%20creation%5D&chfieldfrom=7d&chfieldto=Now&classification=Plasma&list_id=2385376&query_format=advanced last week]
* All the '''feature requests''' reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]
* All bugs reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or in the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]
* All feature requests reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or in the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]
* All crashes reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or in the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]


=== All bug reports of a single product ===
==== All bug reports of a single product ====
You'll want to use the Advanced search for this: https://bugs.kde.org/query.cgi
You'll want to use the Advanced search for this: https://bugs.kde.org/query.cgi


Line 39: Line 46:
* KIO framework [https://bugs.kde.org/buglist.cgi?bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=1506508&product=frameworks-kio&product=kio&product=kio-extras&query_format=advanced bugs] / [https://bugs.kde.org/buglist.cgi?bug_severity=wishlist&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=1506510&product=frameworks-kio&product=kio&product=kio-extras&query_format=advanced feature requests]
* KIO framework [https://bugs.kde.org/buglist.cgi?bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=1506508&product=frameworks-kio&product=kio&product=kio-extras&query_format=advanced bugs] / [https://bugs.kde.org/buglist.cgi?bug_severity=wishlist&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=1506510&product=frameworks-kio&product=kio&product=kio-extras&query_format=advanced feature requests]


= Bug editing permissions =
=== Bug editing permissions ===
All regular Bugzilla users can perform standard editing functions. You can change a number of fields, including the product, component, version, platform, status, and more. You are restricted from only a few abilities, such as bulk editing, changing the Priority and Severity fields (Importance), or re-opening CLOSED bugs. After getting comfortable with the KDE Bugzilla process, you can request "contributor" privileges from Sysadmin, which will allow you to perform those actions.
All regular Bugzilla users can perform standard edits to change fields such as the product, component, version, platform, status, and more. However only users with elevated permissions can do bulk editing, change the Importance fields (Priority and Severity), and re-open CLOSED bugs. After getting comfortable with the KDE Bugzilla process--or if you are the maintainer of a KDE product--you can request those permissions via a [https://phabricator.kde.org/maniphest/task/edit/form/2/ Sysadmin ticket].


= What to do with bug reports =
 
Now that you have a list of bug reports, pick one and start working! Here is the optimal bug triaging workflow:
== Triaging bugs ==
The goal of bug triaging is to ensure that every bugzilla ticket in the bug tracker is actionable for a developer to start working on. All of your actions should work towards this goal. For bugs that cannot be made actionable, they need to be closed. And for those that can, your task is to clean them up so that they can be found and actioned by a developer.


[[File:DarioAndres_GuideToBugTriaging_Workflow.png]]
[[File:DarioAndres_GuideToBugTriaging_Workflow.png]]


{{Note|if at any point you aren't sure how to proceed, move onto the next bug or ask a KDE developers or other more experienced contributor}}
{{Note|If at any point you aren't sure how to proceed, move onto the next bug or ask a KDE developer or another more experienced contributor.}}
 
=== Close bug reports that aren't actionable ===
There are many reasons why a bug report might not be actionable:
 
===== It's not a bug =====
It's common for people to mis-perceive intentional design decisions or features they aren't familiar with as bugs. Some users have the presence of mind to check first on a forum or Reddit or somewhere else, but others jump straight into the bug tracker. In this case, close the bug report as RESOLVED/INTENTIONAL and gently explain to the user that the design or feature is intentional, and that in the future, they might benefit from first asking a question at https://discuss.kde.org.
 
==== It was reported against an old and unsupported version of the software ====
It's also common for people to report bugs against a version of the software that isn't eligible for support from KDE. The Bug Janitor will catch some of these in Plasma, but it won't get them all, and doesn't run at all for bugs on apps and frameworks. In these cases you'll need to handle the situation yourself.
 
Close the bug report as RESOLVED/UNMAINTAINED and gently explain that KDE's resources are so limited that we can't offer support for older, non-LTS versions of the software. A canned response for Plasma [https://invent.kde.org/ngraham/canned-responses#bug-reported-for-plasma-version-thats-out-of-support|can be found here].


== Identify duplicates ==
{{Warning|if you're triaging old bugs, ''everything'' will be reported against an old version, so instead try this canned response: https://invent.kde.org/ngraham/canned-responses#old-bug-report-that-hasnt-been-touched-in-years-that-might-be-fixed-now}}
As KDE has so many users, we get a lot of reports about bugs which have already been reported (duplicates). Before putting any effort in the current report, check for an existing report. If you find a pre-existing bug report describing the same issue, mark this one as a duplicate of it.


Please see [[Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates|the article on identifying duplicates]].
==== It's a duplicate of an existing bug report ====
As KDE has so many users, we get a lot of reports about bugs which have already been reported but not yet fixed. Identifying these is mostly a matter of experience, but if the bug being reported is reproducible and extremely obvious, it's quite likely it's already been reported somewhere, so mark it as a duplicate of the existing bug report. See [[Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates|the article on identifying duplicates]] for specific instructions on how to find duplicate issues.


== Identify bugs caused by external issues (UPSTREAM/DOWNSTREAM) ==
==== It's a bug, but it was already fixed ====
Not all real bugs affecting KDE software are actually caused by a fault in KDE software. The issue may be "upstream" or "downstream" of KDE.
It's common for people to report bugs that have already been fixed in an upcoming version of the software. If there's an existing bug report for it, mark it as a duplicate of that one. If not, close it as RESOLVED/FIXED and fill in the "version fixed in" field with the upcoming version that will have the fix in it.


"Upstream" means that the problem lies in an underlying technology that KDE software uses (e.g. Qt, X11, the Linux kernel). Others who make use of KDE software (e.g Linux distributions, 3rd party Plasma plugins) are '''downstream''' of KDE.
==== It's a bug, but not a KDE bug (i.e. UPSTREAM/DOWNSTREAM issues) ====
KDE software sits on top of a very tall software stack. Many layers of this stack will provide functionality that KDE apps use, but don't provide themselves. As a result, not all real bugs affecting KDE software are actually caused by issues in KDE software! The issue may be "upstream" or "downstream" of KDE.


Examples of Upstream issues:
"Upstream" means that the problem lies in an underlying technology that KDE software uses (e.g. Qt, X11, the Linux kernel). Others who make use of KDE software (e.g Linux distributions, 3rd party apps or Plasma plugins) are '''downstream''' of KDE.
* KDE app experiences a new behavioral issue after upgrading to a newer version of Qt
* KDE app crashes in QtQuick
* KDE app experiences an issue, but only when using the proprietary NVIDIA driver


; Examples of Upstream issues:
* A KDE app experiences a new behavioral issue after upgrading to a newer version of Qt.
* A KDE app crashes in QtQuick.
* A KDE app experiences an issue, but only when using the proprietary NVIDIA driver.


Examples of Downstream issues:
If a bug is deemed to be caused by upstream software, it's ideal if it's tracked by a bug report in the affected project. If one exists, put it in the URL field of the KDE bug report and then close it as RESOLVED/UPSTREAM. Of no such upstream bug report exists or can be found, you can encourage the reporter to submit one themselves (and then put it in the URL field of the KDE bug report) if they seem very technically knowledgeable. Otherwise, submit one yourself on behalf of the bug reporter.


* A KDE app crashes because a dependent package is not automatically installed by the user's distro
; Examples of Downstream issues:
* Fonts are really hard to read, but only in certain distros
* A KDE app crashes because a dependent package is not automatically installed by the user's distro.
* Graphical corruption with a Plasma theme downloaded from store.kde.org
* Fonts are really hard to read, but only in certain distros.
* Graphical corruption with a Plasma theme downloaded from store.kde.org.


== Ask for any missing information ==
If a bug is caused by downstream software, it's acceptable to close it as RESOLVED/DOWNSTREAM and let the bug reporter report it there themselves.  
Now that you know that the bug report is unique and that it is not an external issue, you need to check that all the needed information is there.


* If the reporter has not entered the Platform correctly (i.e., it is "unspecified/Linux"), then ask which platform/distro they are using. This can help determine if there are distro/downstream bugs. Mark the bug as NEEDSINFO/WAITINGFORINFO.
==== It's a feature request that would be impossible or impractical to implement ====
* If the description is not written in English and you cannot understand it, you may want to ask other KDE contributors to translate it for you. Alternatively, you can ask the reporter to use some online translation system.
In general we try to be lenient with feature requests, but sometimes people offer up ideas that would be impossible to implement, or consume so many development resources as to be impractical, or amount to requests to re-engineer the entire world. In these cases, gently explain that feature requests need to be narrowly-tailored and implementable, and close the bug as RESOLVED/INTENTIONAL. If the reporter seems technically competent and ambitious, you might consider encouraging them to work on it themselves.
* If the reporter has not indicated what versions of KDE Plasma, Qt, and KDE Frameworks they are using, ask them to provide that information ([[Get Involved/Bug Reporting#Software_versions]])
* If the explanation is not clear enough, ask for clarification and concrete steps to reproduce ([[Get Involved/Bug Reporting#Steps to Reproduce]])
* If the issue is hard to picture without a visual aid and there are no screenshots or a screen recording attached, ask for one ([[Get Involved/Bug Reporting#Screenshots and screen recordings]])
* If the bug report is about a crash and the backtrace information is not complete, ask the user to install the missing debug symbols package, reproduce the bug, and generate a new backtrace. ([[Guidelines and HOWTOs/Debugging/How to create useful crash reports]])


=== Polish up any bug reports that are or might be actionable ===
At this point, the bug report might be a real actionable issue that can be fixed by a KDE developer. Great! Let's help it stand out from the rest and be easily findable and actionable.


{{Note| After asking for further information, mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" (or resolution "BACKTRACE" if you are waiting for a complete backtrace)}}
==== Move it to the right place ====
There are many products on KDE's Bugzilla, so it's common for a bug report to be submitted to the wrong one. We even encourage people to report bugs to the generic "kde" product if they don't know what to do. This is fine; just move it to the right place.


== Reproduce the bug ==
Where bug reports should live is something that mostly needs to be learned over time, but you can check the [[Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates#List_of_related_KDE_technologies|KDE related technologies list]] for a start. Sometimes errors are obvious, such as when a bug report is about an app but it's reported against the "plasmashell" product.
At this point, the bug report enough is complete enough that you should use the information provided by the reporter and try to make the bug appear on your own system.


{{Note|It is important to have up-to-date KDE components installed to test bugs. Only try to reproduce bugs using the latest versions of KDE software, or even development versions}}
{{Warning|Only reassign the bug report if you're sure it's in the wrong product.}}


{{Warning|Testing bug reports may modify/alter your own desktop configuration; also, to try to reproduce some bugs you may need a clean pristine (or slightly modified) environment. We recommend you to perform tests on a separate KDE installation or a clean user. There is also a way to start KDE applications with a clean configuration, even under your current configuration (setting the KDEDIR environment variable at run-time to an empty directory).}}
==== Fix obvious metadata field errors ====
Quickly go through the bug report's metadata; fields like version, platform, severity, and so on, and correct them. For example:
* If the user listed the platform or version fields in a way that doesn't match the information in the body of the bug report, set the fields to match the text.
* If the user reported a feature but didn't use the "wishlist" severity, change it to wishlist.
* If the user reported a feature, but phrased it as a bug report (e.g. "Error: app can't do [thing that it currently doesn't do]"), rephrase the title and change the severity to wishlist.


You may want to use this reference text to setup your testing environment: [http://forum.kde.org/viewtopic.php?f=9&t=84475 Preparing a testing environment]
{{Note|The "version" field is for reporting the ''latest'' version that the bug has been reproduced against, not the original version.}}


If you can't reproduce with any scenario mentioned in the comments, you may want to try other related situations. Write down any newly discovered steps to reproduce.
If the correct version or platform is missing from the list, contact the software maintainer or the KDE Bugzilla admins to get this corrected.


=== If you cannot reproduce the bug under any circumstances ===
==== If it's a reasonable wishlist ====
Write down the steps you performed. Ask the reporter if your steps missed something, or if anyone notices any other strange or non-default situation or configuration which may be related. Also ask the reporter for more information and mark it NEEDSINFO/WAITINGFORINFO.
In general we try to be lenient with feature requests, so if the requested feature seems at all reasonable and feasible to implement to you, mark it as CONFIRMED.


Hopefully, you will get feedback from the reporters and you could gather more information to try to reproduce the bug or close the report as RESOLVED/WORKSFORME (or FIXED) after a short wait.
==== Ask for any missing information ====
Now it's time to fill in missing info.


=== If you can reproduce the bug ===
Every time you ask a bug reporter for information, put the bug report in NEEDSINFO/WAITINGFORINFO status. This does two things:
If you had to combine several steps to make your own "recipe" to reproduce, write them down. This kind of information is useful for the developers. If you had to use custom input data (text, or a file), you may want to attach it to the bug report. Don't forget to mention the environment and circumstances under which you can reproduce the bug.
* Hides the bug report from lists of open bugs
* Closes the bug report automatically if there's no response after a month


== Set Bugzilla fields ==
Things that commonly need asking about:
Often a bug report isn't properly categorized, or lacks some information in the Bugzilla fields (which are useful for sorting and filtering). If a field isn't mentioned below, you don't need to change it. All users have permission to change most Bugzilla fields.
* If the explanation is not clear enough for you to easily understand what the problem is and how you can test it, ask for clarification and concrete steps to reproduce. ([[Get Involved/Bug Reporting#Steps to Reproduce]])
* If the issue is hard to picture without a visual aid and there are no screenshots or a screen recording attached, ask for one. ([[Get Involved/Bug Reporting#Screenshots and screen recordings]])
* If the bug report is about a crash and they did not attach a backtrace, or the backtrace information is incomplete or lacking debug symbols, ask the user to install the missing debug symbols packages, reproduce the bug, and generate a new backtrace. When you do this, set the status to NEEDSINFO/BACKTRACE. Relevant canned responses: [https://invent.kde.org/ngraham/canned-responses#crash-with-no-backtrace|"no backtrace"] and [https://invent.kde.org/ngraham/canned-responses#crash-backtrace-missing-debug-symbols| backtrace missing debug symbols]
* If the reporter has not entered the platform (i.e. it's "unspecified/Linux") and they didn't indicate which platform/distro they're using in the text, ask them.
* If the reporter has not indicated what versions of KDE Plasma, Qt, and KDE Frameworks they are using, ask them to provide that information, and also set the version field accordingly.


=== Product ===
=== Reproduce the bug ===
Many bug reports are reported against the wrong product. This may happen because the original reporter didn't know which application/library the bug belongs to. For example, many bugs filed to Dolphin are actually about KIO (the I/O framework) or Baloo (the search frameworks). Remember to check the [[Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates#List_of_related_KDE_technologies|KDE related technologies list]]
At this point, the bug report is complete enough that you should use the information provided by the reporter and try to make the bug appear on your own system.


{{Warning|Only reassign if you are sure the bug is in the wrong product.}}
==== If you cannot reproduce the bug under any circumstances ====
=== Component ===
Write this down, and mention the software version and distro you tested on. Ideally also write down the steps you performed.
As with the Product field, many bug reports are reported against the wrong component or none at all. Set the Component if you are able to determine a more appropriate one than the bugs current assignment.


=== Version===
Consider asking the reporter if your testing missed something, or if anyone notices any other strange or non-default situation or configuration which may be related. Hopefully, they'll provide feedback that can help you reproduce the issue. If you still can't reproduce the issue under any circumstances, leave the bug in REPORTED state and move onto the next one. Hopefully someone else can reproduce it, or a developer with more technical knowledge can help.
If the report has an application version, you need to set the version in the Bugzilla field. Ideally the version field should reflect the latest version the bug is reproducible with. If the version is missing in the list, please contact the software maintainer or the KDE Bugzilla admins to add the version.


=== Platform  ===
==== If you can reproduce the bug ====
This field is only important if the bug is related to one distribution or a specific system (most of the bug reports are common to most of the platforms).
Set the bug's status to CONFIRMED and write that you can reproduce the bug on your system, mentioning the version if it's newer than what the bug reporter is using. If the way you reproduced the bug differs from how the reporter reported it, write that down too.


=== Severity ===
It's also acceptable to mark a bug report as CONFIRMED if it has multiple duplicates even if you cannot personally reproduce the issue; clearly it is something real if multiple people are experiencing it the same issue.
Mark the bug's severity. Some hints about the various severity options:
* '''Critical''': A widespread, easily reproducible issue that causes data loss.
* '''Grave''': The software is basically unusable, with no workaround.
* '''Major''': A major feature is broken, and the workaround (if any) is painful and difficult.
* '''Crash''': The software crashes or hangs.
* '''Normal''': It's a bug that should be fixed, possibly with a reasonable workaround.
* '''Minor''': Minor cosmetic issue or loss of function with an easy workaround.
* '''Wishlist''': Request for a new feature or enhancement.


=== Keywords ===
==== Set the Severity field ====
If the bug seems like it would be really easy to fix, add the "junior-jobs" keyword. Examples of issues that would be easy to fix:
Mark the bug's severity according to these definitions:
* Inaccurate description or text label
* Visual layout inconsistencies
* Pixellated icons when an app is run in HiDPI mode
* User interface element is the wrong color when using Breeze Dark


New code contributors often start with "junior-jobs" bugs, so ensuring that there is a steady supply of bugs tagged with this keyword helps them get started with small, manageable tasks.
{| class="wikitable"
|-
! Severity !! When to use it
|-
| Critical || A widespread, easily reproducible issue '''that causes data loss'''
|-
| Grave || The software becomes basically unusable, with no known workaround
|-
| Major || Like Normal, but with no known workaround, or the workaround is painful and difficult
|-
| Crash || The software crashes or hangs
|-
| Normal || Something isn't working the way it was designed to work, with a known workaround that isn't too painful
|-
| Minor || A cosmetic issue, awkward UX, or weird interaction between non-default yet supported components
|-
| Wishlist || An idea for how the product could become better in the future by doing something it currently doesn't do
|-
| Task || A technical maintenance chore like porting to a new API or refactoring some code to reduce future bugginess
|}


If the bug involves a poor user interface or demands a tedious workflow, tag it with the "usability" keyword, and it will be considered a part of KDE's [https://phabricator.kde.org/T6831|"Usability & productivity" initiative].
==== Set relevant Keywords ====
Set whichever keywords from this table are relevant:


=== Status ===
{| class="wikitable"
If you can reproduce the issue, ''and you are confident that you have set all fields correctly'', set the bug report's status to CONFIRMED. This only applies to bugs; feature requests ("wishlist" items) don't need to be confirmed, since they're not bugs.
|-
! Keyword !! When to apply it
|-
| regression || Something that worked in the past, but is now broken
|-
| usability || Something that involves a poor user interface or demands a tedious workflow
|-
| junior-jobs || A bug that seems like it would be really easy to fix. Examples include inaccurate text, visual layout inconsistencies, and user interface elements using the wrong color with Breeze Dark
|-
| wayland || A bug that only manifests on Wayland
|-
| qt6 || A bug that only manifests on software build with Qt 6
|}


== Rename the bug report ==
==== Rename it if needed ====
The bug report's summary might not accurately represent the bug, especially after you have triaged the bug and found the root cause or determined it to be another issue. You may want to update the summary to contain enough information to identify the issue properly. A good summary:
The bug report's summary might not accurately represent the bug, especially after you've triaged the bug and found the root cause or determined it to be another issue. You may want to update the summary to contain enough information to identify the issue properly. A good summary:


* Is readable as a grammatically correct English sentence
* Is readable as a grammatically correct English sentence
Line 152: Line 199:
* Isn't too long
* Isn't too long


= Special circumstances =
=== Bug describes multiple issues ===
You must close the bug report as RESOLVED/NOT A BUG with a '''humane''' explanation that bug reports can only contain a single issue. ([[Get Involved/Bug Reporting#One issue per bug report]])


=== Bug includes a patch ===
== Special circumstances ==
If the bug reporter or someone else included a patch, ask them to submit it using Phabricator, and remind them about [[Get Involved/Bug Reporting#Submit patches using Phabricator.2C not the bug tracker]]
=== Common yet tricky bugs ===
There are a few persistent categories of bug reports that can have multiple underlying root causes and require specialized knowledge and handling. See theme at [[Guidelines_and_HOWTOs/Bug_triaging/Tricky_bugs]].
 
=== Bug report describes multiple issues ===
Close the bug report as RESOLVED/NOT A BUG with a '''humane''' explanation that bug reports can only contain a single issue. ([[Get Involved/Bug Reporting#One issue per bug report]]). Sample text can be found at https://invent.kde.org/ngraham/canned-responses#multiple-issues.


=== Reporter seems very technically knowledgeable ===
=== Bug report includes a patch ===
Sometimes a very technically knowledgeable bug reporter will correctly identify the source of the issue, and maybe even the exact line of code that's causing the problem. Encourage them to submit a patch, and point them to https://community.kde.org/Get_Involved/development
If the bug reporter or someone else included a patch, ask them to submit it using GitLab, and remind them about [[Get_Involved/Issue_Reporting#Submit_patches_using_GitLab.2C_not_the_issue_tracker]].
 
=== Bug reporter seems very technically knowledgeable ===
Sometimes a very technically knowledgeable bug reporter will correctly identify the source of the issue, and maybe even the exact line of code that's causing the problem. Encourage them to submit a patch, and point them to https://community.kde.org/Get_Involved/development.


=== Same person reports a lot of bugs ===
=== Same person reports a lot of bugs ===
Anybody who reports a lot of KDE bugs--especially if they are high quality bugs--is quite likely a committed KDE user who is a good candidate for becoming a more involved contributor over time. '''Stumbling on someone like this in the bug tracker is like striking gold.''' Take every opportunity to develop a relationship with this person and try to guide them through the KDE "[[Get Involved|get involved]]" pipeline. Oftentimes people who submit a lot of bugs move on to bug triaging and then later development.
Anybody who reports a lot of KDE bugs--especially if they are high quality bugs--is quite likely a committed KDE user who is a good candidate for becoming a more involved contributor over time. '''Stumbling on someone like this in the bug tracker is like striking gold.''' Take every opportunity to develop a relationship with this person and try to guide them through the KDE "[[Get Involved|get involved]]" pipeline. Oftentimes people who submit a lot of bugs move on to bug triaging and then later development.


= Policies =
 
* Bugs placed into NEEDSINFO status will receive a reminder if the ticket:
== Bug Janitor ==
** Is at least 15 days old
KDE bug reports are overseen by a basic [https://invent.kde.org/sysadmin/bugzilla-bot bug janitor bot] that does the following things:
** Has not received any comment within 15 days
* Nudges bugs in NEEDSINFO status after 15 days with no response
* If a bug remains in NEEDSINFO for another 15 days with no comment, it will be closed as RESOLVED > WORKSFORME.
* Closes bug reports in NEEDSINFO status as RESOLVED/WORKSFORME after 30 days with no response
* If a bug remains in NEEDSINFO with a comment provided within less than 15 days, no action will be taken (as it does not meet the above criteria).
* Automatically sets the severity to "crash" if the title matches any of various keywords (e.g. "crash", and "coredump")
* Automatically sets the severity to "wishlist" if the title matches any of various keywords (e.g. "feature request", and "wish")
* Increases the priority to HI when a bug report has 5 duplicates
* Increases the priority to VHI when a bug report has 10 duplicates
* Closes Plasma bugs with a gentle message that were reported against a version that's neither the latest released version nor the latest LTS version

Latest revision as of 18:27, 23 October 2023

Help Konqi catch some bugs!

KDE's bug triagers go through new and old bug reports to make sure they're actionable for developers. We verify that a bug exists, whether it is reproducible, and that the reporter has provided enough information for developers to action it. Our goal is to save developers from this task, which helps them fix bugs more quickly and do more work on KDE software.

One of the great things about bug triaging is that you don't need any programming knowledge, only basic familiarity with KDE software and a rough overview of how the Linux software stack is arranged (e.g. Plasma on top, Qt below it, various middleware libraries below Qt, and the kernel at the bottom).

That said, experience has shown that members of this team learn a lot about KDE and Qt programming during the course of dealing with bug reports, and many move on to developing the software itself. If you're just starting to learn programming, bug triaging is a great way to gain familiarity with the technical details of KDE's software architecture and provide practical support to the KDE community.

When you start bug triaging, an existing member can help you out as a mentor. Just stop by the KDE Bugs Matrix group and introduce yourself!

Getting started

General considerations

  • Be polite. Bug triagers are the face of KDE. Be nice to bug reporters, even if they aren't nice to you! You have an opportunity to showcase the best of the KDE community, and turn skeptics into fans. Being nice is more impactful than being right.
  • Explain your decisions. It can be very frustrating for a bug reporter if their report is suddenly closed without any reason given. Especially when you close a bug report, write why you think your action is the correct one, and don't establish your opinion as the all-ruling fact. Some canned responses and explanations that have been shown to work well can be found at https://invent.kde.org/ngraham/canned-responses.
  • Don't be afraid to make mistakes. Everybody makes mistakes, especially when starting out with bug triaging.
  • KDE uses the Bugzilla bug tracker system. If you are not familiar with it, you may find this quick Introduction to Bugzilla useful.

System Setup

It's very important to be using the latest versions of KDE software. In general, only the latest version is supported, and it's common for people to report bugs against old versions, so you need to be able to identify this situation.

It's highly recommended to use a rolling release or semi-rolling distro, such as Arch or an Arch derivative, KDE Neon, Fedora KDE, or openSUSE Tumbleweed. Ideally you'll be daily-driving such a distro, but if not, using it in a VM for bug triage purposes is better than nothing.

Slow discrete release distros like Ubuntu, Debian, and openSUSE Leap are not recommended.

Decide what to work on

All bugs filed recently

Going through all bugs submitted recently in an organized manner is hugely impactful. Here are some links to Bugzilla searches that will update automatically over time:

All bug reports of a single product

You'll want to use the Advanced search for this: https://bugs.kde.org/query.cgi

You can see which products are most in need of bug triaging here, with links to their bug lists: https://bugs.kde.org/weekly-bug-summary.cgi?tops=50&days=7

Here are some common and popular KDE products in need of bug triaging:

Bug editing permissions

All regular Bugzilla users can perform standard edits to change fields such as the product, component, version, platform, status, and more. However only users with elevated permissions can do bulk editing, change the Importance fields (Priority and Severity), and re-open CLOSED bugs. After getting comfortable with the KDE Bugzilla process--or if you are the maintainer of a KDE product--you can request those permissions via a Sysadmin ticket.


Triaging bugs

The goal of bug triaging is to ensure that every bugzilla ticket in the bug tracker is actionable for a developer to start working on. All of your actions should work towards this goal. For bugs that cannot be made actionable, they need to be closed. And for those that can, your task is to clean them up so that they can be found and actioned by a developer.

Note

If at any point you aren't sure how to proceed, move onto the next bug or ask a KDE developer or another more experienced contributor.


Close bug reports that aren't actionable

There are many reasons why a bug report might not be actionable:

It's not a bug

It's common for people to mis-perceive intentional design decisions or features they aren't familiar with as bugs. Some users have the presence of mind to check first on a forum or Reddit or somewhere else, but others jump straight into the bug tracker. In this case, close the bug report as RESOLVED/INTENTIONAL and gently explain to the user that the design or feature is intentional, and that in the future, they might benefit from first asking a question at https://discuss.kde.org.

It was reported against an old and unsupported version of the software

It's also common for people to report bugs against a version of the software that isn't eligible for support from KDE. The Bug Janitor will catch some of these in Plasma, but it won't get them all, and doesn't run at all for bugs on apps and frameworks. In these cases you'll need to handle the situation yourself.

Close the bug report as RESOLVED/UNMAINTAINED and gently explain that KDE's resources are so limited that we can't offer support for older, non-LTS versions of the software. A canned response for Plasma be found here.

Warning

if you're triaging old bugs, everything will be reported against an old version, so instead try this canned response: https://invent.kde.org/ngraham/canned-responses#old-bug-report-that-hasnt-been-touched-in-years-that-might-be-fixed-now


It's a duplicate of an existing bug report

As KDE has so many users, we get a lot of reports about bugs which have already been reported but not yet fixed. Identifying these is mostly a matter of experience, but if the bug being reported is reproducible and extremely obvious, it's quite likely it's already been reported somewhere, so mark it as a duplicate of the existing bug report. See the article on identifying duplicates for specific instructions on how to find duplicate issues.

It's a bug, but it was already fixed

It's common for people to report bugs that have already been fixed in an upcoming version of the software. If there's an existing bug report for it, mark it as a duplicate of that one. If not, close it as RESOLVED/FIXED and fill in the "version fixed in" field with the upcoming version that will have the fix in it.

It's a bug, but not a KDE bug (i.e. UPSTREAM/DOWNSTREAM issues)

KDE software sits on top of a very tall software stack. Many layers of this stack will provide functionality that KDE apps use, but don't provide themselves. As a result, not all real bugs affecting KDE software are actually caused by issues in KDE software! The issue may be "upstream" or "downstream" of KDE.

"Upstream" means that the problem lies in an underlying technology that KDE software uses (e.g. Qt, X11, the Linux kernel). Others who make use of KDE software (e.g Linux distributions, 3rd party apps or Plasma plugins) are downstream of KDE.

Examples of Upstream issues
  • A KDE app experiences a new behavioral issue after upgrading to a newer version of Qt.
  • A KDE app crashes in QtQuick.
  • A KDE app experiences an issue, but only when using the proprietary NVIDIA driver.

If a bug is deemed to be caused by upstream software, it's ideal if it's tracked by a bug report in the affected project. If one exists, put it in the URL field of the KDE bug report and then close it as RESOLVED/UPSTREAM. Of no such upstream bug report exists or can be found, you can encourage the reporter to submit one themselves (and then put it in the URL field of the KDE bug report) if they seem very technically knowledgeable. Otherwise, submit one yourself on behalf of the bug reporter.

Examples of Downstream issues
  • A KDE app crashes because a dependent package is not automatically installed by the user's distro.
  • Fonts are really hard to read, but only in certain distros.
  • Graphical corruption with a Plasma theme downloaded from store.kde.org.

If a bug is caused by downstream software, it's acceptable to close it as RESOLVED/DOWNSTREAM and let the bug reporter report it there themselves.

It's a feature request that would be impossible or impractical to implement

In general we try to be lenient with feature requests, but sometimes people offer up ideas that would be impossible to implement, or consume so many development resources as to be impractical, or amount to requests to re-engineer the entire world. In these cases, gently explain that feature requests need to be narrowly-tailored and implementable, and close the bug as RESOLVED/INTENTIONAL. If the reporter seems technically competent and ambitious, you might consider encouraging them to work on it themselves.

Polish up any bug reports that are or might be actionable

At this point, the bug report might be a real actionable issue that can be fixed by a KDE developer. Great! Let's help it stand out from the rest and be easily findable and actionable.

Move it to the right place

There are many products on KDE's Bugzilla, so it's common for a bug report to be submitted to the wrong one. We even encourage people to report bugs to the generic "kde" product if they don't know what to do. This is fine; just move it to the right place.

Where bug reports should live is something that mostly needs to be learned over time, but you can check the KDE related technologies list for a start. Sometimes errors are obvious, such as when a bug report is about an app but it's reported against the "plasmashell" product.

Warning

Only reassign the bug report if you're sure it's in the wrong product.


Fix obvious metadata field errors

Quickly go through the bug report's metadata; fields like version, platform, severity, and so on, and correct them. For example:

  • If the user listed the platform or version fields in a way that doesn't match the information in the body of the bug report, set the fields to match the text.
  • If the user reported a feature but didn't use the "wishlist" severity, change it to wishlist.
  • If the user reported a feature, but phrased it as a bug report (e.g. "Error: app can't do [thing that it currently doesn't do]"), rephrase the title and change the severity to wishlist.

Note

The "version" field is for reporting the latest version that the bug has been reproduced against, not the original version.


If the correct version or platform is missing from the list, contact the software maintainer or the KDE Bugzilla admins to get this corrected.

If it's a reasonable wishlist

In general we try to be lenient with feature requests, so if the requested feature seems at all reasonable and feasible to implement to you, mark it as CONFIRMED.

Ask for any missing information

Now it's time to fill in missing info.

Every time you ask a bug reporter for information, put the bug report in NEEDSINFO/WAITINGFORINFO status. This does two things:

  • Hides the bug report from lists of open bugs
  • Closes the bug report automatically if there's no response after a month

Things that commonly need asking about:

  • If the explanation is not clear enough for you to easily understand what the problem is and how you can test it, ask for clarification and concrete steps to reproduce. (Get Involved/Bug Reporting#Steps to Reproduce)
  • If the issue is hard to picture without a visual aid and there are no screenshots or a screen recording attached, ask for one. (Get Involved/Bug Reporting#Screenshots and screen recordings)
  • If the bug report is about a crash and they did not attach a backtrace, or the backtrace information is incomplete or lacking debug symbols, ask the user to install the missing debug symbols packages, reproduce the bug, and generate a new backtrace. When you do this, set the status to NEEDSINFO/BACKTRACE. Relevant canned responses: "no backtrace" and backtrace missing debug symbols
  • If the reporter has not entered the platform (i.e. it's "unspecified/Linux") and they didn't indicate which platform/distro they're using in the text, ask them.
  • If the reporter has not indicated what versions of KDE Plasma, Qt, and KDE Frameworks they are using, ask them to provide that information, and also set the version field accordingly.

Reproduce the bug

At this point, the bug report is complete enough that you should use the information provided by the reporter and try to make the bug appear on your own system.

If you cannot reproduce the bug under any circumstances

Write this down, and mention the software version and distro you tested on. Ideally also write down the steps you performed.

Consider asking the reporter if your testing missed something, or if anyone notices any other strange or non-default situation or configuration which may be related. Hopefully, they'll provide feedback that can help you reproduce the issue. If you still can't reproduce the issue under any circumstances, leave the bug in REPORTED state and move onto the next one. Hopefully someone else can reproduce it, or a developer with more technical knowledge can help.

If you can reproduce the bug

Set the bug's status to CONFIRMED and write that you can reproduce the bug on your system, mentioning the version if it's newer than what the bug reporter is using. If the way you reproduced the bug differs from how the reporter reported it, write that down too.

It's also acceptable to mark a bug report as CONFIRMED if it has multiple duplicates even if you cannot personally reproduce the issue; clearly it is something real if multiple people are experiencing it the same issue.

Set the Severity field

Mark the bug's severity according to these definitions:

Severity When to use it
Critical A widespread, easily reproducible issue that causes data loss
Grave The software becomes basically unusable, with no known workaround
Major Like Normal, but with no known workaround, or the workaround is painful and difficult
Crash The software crashes or hangs
Normal Something isn't working the way it was designed to work, with a known workaround that isn't too painful
Minor A cosmetic issue, awkward UX, or weird interaction between non-default yet supported components
Wishlist An idea for how the product could become better in the future by doing something it currently doesn't do
Task A technical maintenance chore like porting to a new API or refactoring some code to reduce future bugginess

Set relevant Keywords

Set whichever keywords from this table are relevant:

Keyword When to apply it
regression Something that worked in the past, but is now broken
usability Something that involves a poor user interface or demands a tedious workflow
junior-jobs A bug that seems like it would be really easy to fix. Examples include inaccurate text, visual layout inconsistencies, and user interface elements using the wrong color with Breeze Dark
wayland A bug that only manifests on Wayland
qt6 A bug that only manifests on software build with Qt 6

Rename it if needed

The bug report's summary might not accurately represent the bug, especially after you've triaged the bug and found the root cause or determined it to be another issue. You may want to update the summary to contain enough information to identify the issue properly. A good summary:

  • Is readable as a grammatically correct English sentence
  • Contains a brief explanation of the root cause (if it was found)
  • Includes some of the symptoms people are experiencing
  • Includes ClassName::FunctionName pairs if the bug describes a crash
  • Isn't too long


Special circumstances

Common yet tricky bugs

There are a few persistent categories of bug reports that can have multiple underlying root causes and require specialized knowledge and handling. See theme at Guidelines_and_HOWTOs/Bug_triaging/Tricky_bugs.

Bug report describes multiple issues

Close the bug report as RESOLVED/NOT A BUG with a humane explanation that bug reports can only contain a single issue. (Get Involved/Bug Reporting#One issue per bug report). Sample text can be found at https://invent.kde.org/ngraham/canned-responses#multiple-issues.

Bug report includes a patch

If the bug reporter or someone else included a patch, ask them to submit it using GitLab, and remind them about Get_Involved/Issue_Reporting#Submit_patches_using_GitLab.2C_not_the_issue_tracker.

Bug reporter seems very technically knowledgeable

Sometimes a very technically knowledgeable bug reporter will correctly identify the source of the issue, and maybe even the exact line of code that's causing the problem. Encourage them to submit a patch, and point them to https://community.kde.org/Get_Involved/development.

Same person reports a lot of bugs

Anybody who reports a lot of KDE bugs--especially if they are high quality bugs--is quite likely a committed KDE user who is a good candidate for becoming a more involved contributor over time. Stumbling on someone like this in the bug tracker is like striking gold. Take every opportunity to develop a relationship with this person and try to guide them through the KDE "get involved" pipeline. Oftentimes people who submit a lot of bugs move on to bug triaging and then later development.


Bug Janitor

KDE bug reports are overseen by a basic bug janitor bot that does the following things:

  • Nudges bugs in NEEDSINFO status after 15 days with no response
  • Closes bug reports in NEEDSINFO status as RESOLVED/WORKSFORME after 30 days with no response
  • Automatically sets the severity to "crash" if the title matches any of various keywords (e.g. "crash", and "coredump")
  • Automatically sets the severity to "wishlist" if the title matches any of various keywords (e.g. "feature request", and "wish")
  • Increases the priority to HI when a bug report has 5 duplicates
  • Increases the priority to VHI when a bug report has 10 duplicates
  • Closes Plasma bugs with a gentle message that were reported against a version that's neither the latest released version nor the latest LTS version