Guidelines and HOWTOs/Bug triaging: Difference between revisions

From KDE Community Wiki
m (Ochurlaud moved page Bugsquad/Guide To BugTriaging to Guidelines and HOWTOs/Bug triaging: It goes there)
m (Fixed two broken links)
 
(65 intermediate revisions by 18 users not shown)
Line 1: Line 1:
Initial version by [[User:DarioAndres|Dario Andres]] (2010-03/2010-04).
[[File:Mascot konqi-support-bughunt.png|thumbnail|right|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.'''


Initial corrections by Lydia Pintscher (Nightrose)
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).


===Disclaimer===
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.


This "ultimate" guide is based on my own experience (approximately 2 years) on the KDE bug tracker.
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!


I hope it works for you too :)
== 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.


=General Considerations=
=== 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.


* '''Be polite''': when you need to request information or feedback be clear and polite, and you will get more information in less time. 
Often Bugzilla is a place which involves discussions (about implementations, or even about contributors). Try to be concise and polite, respecting the other's position while describing your own.
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.


* Don't try to do too many things at the same time; otherwise you will end up with a headache.
Slow discrete release distros like Ubuntu, Debian, and openSUSE Leap are not recommended.


If you are not familiar with the Bugzilla (KDE bug tracker system) interface, you may find this guide useful: [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla Quick Introduction to Bugzilla]
=== 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 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 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 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]


You may want to properly setup your bugzilla account as mentioned at [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla#Configure_your_account_.28Important.29 Configure your account]
==== All bug reports of a single product ====
You'll want to use the Advanced search for this: https://bugs.kde.org/query.cgi


=About getting permissions to work in the bug tracker=
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


Manpower is always needed in a bug tracker, but as any action taken on it may be potentially destructive to other people's work; or it may end up messing things up (and consuming the developers' or other triager's time) the tracker requires special permissions to perform changes in bug reports.
Here are some common and popular KDE products in need of bug triaging:
* Plasma [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=1506503&product=plasmashell&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=1506504&product=plasmashell&query_format=advanced feature requests]
* System Settings [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=1506503&product=systemsettings&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=1506504&product=systemsettings&query_format=advanced feature requests]
* Dolphin [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=1506503&product=dolphin&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=1506504&product=dolphin&query_format=advanced feature requests]
* Okular [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=1506503&product=okular&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=1506504&product=okular&query_format=advanced feature requests]
* Gwenview [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=1506503&product=gwenview&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=1506504&product=gwenview&query_format=advanced feature requests]
* Konsole [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=1506503&product=konsole&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=1506504&product=konsole&query_format=advanced feature requests]
* Kate & KTextEditor 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=1506507&product=frameworks-ktexteditor&product=kate&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=1506506&product=frameworks-ktexteditor&product=kate&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]


If you want to work in the bug tracker you need to prove that you know what you are doing.
=== 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 [https://phabricator.kde.org/maniphest/task/edit/form/2/ Sysadmin ticket].


Initially you will ask for support on '''#kde-bugs''' (on IRC) and add comments in the bug report (so other people will see and check them, perform the needed actions, and evaluate your work)


{{Note|Adding comments in a bug report is allowed for every user}}
== 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.
=Getting Started: Find what to work on (Different Approaches)=
 
You could use different techniques or approaches to triage the reports according to your current mood or the amount of work you want to do for example.
 
{{Tip|The two following techniques are complementary.}}
 
==Check all the bug reports of the day==
 
In this technique you check all the bug reports (of all the products) which were filed today (or some days ago).
 
You can focus on crash, normal or wish reports individually (recommended) or all of them together.
 
'''Good:'''
* You get a complete view of all the reports
* You can easily recognize possible duplicates if the report titles are appropriate
* You can choose any report
* You can quickly clean the bugs that were filed recently (keeping them from rotting)
* You can get quick feedback from the reporter
 
'''Not so Good:'''
* You don't focus on one product
* You may not pay too much attention to every report, as you are triaging different kinds of reports
* You need a lot of attention to handle the different reports (at the ~same~ time)
 
This technique could be used ''every week'' (or every day)
 
===Bugzilla Links===
* 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]
* 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 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 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]
 
==Check bug reports of a single product over a period of time==
 
Choose a product (application or library). Then choose a period of time like 1 month or 1 or 2 years (or "from the beginning of the current year", or even from the very beggining (like 2000)). You can also choose which kind of reports you want to handle.
 
This technique is useful to audit old bugs or perform a deep clean (in case that the bugs weren't triaged on a daily basis previously).
 
'''Good:'''
* You focus only on one product / topic, so you don't need to pay too much attention (pay attention anyways!)
 
'''Not so Good:'''
* The reports of the other application may rot if they aren't checked
* You may not get feedback if the report is too old or the reporter is not accessible anymore
 
You can also filter out results (and be even more focused) if you select a custom component inside the product (a subsection of the application).
 
This technique could be used ''two times a month''.
 
===Bugzilla Links===
 
* Template search for all the reports of any status, since 2008: [https://bugs.kde.org/query.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfield=%5BBug%20creation%5D&chfieldfrom=2008-01-01&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=bug_severity&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=plasma&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=plasma&value-1-1-0=crash&value0-0-0=&votes= any kind of report], [https://bugs.kde.org/query.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_severity=crash&bugidtype=include&chfield=%5BBug%20creation%5D&chfieldfrom=2008-01-01&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=bug_severity&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=plasma&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=plasma&value-1-1-0=crash&value0-0-0=&votes= crashes], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&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= normal bugs], [https://bugs.kde.org/query.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_severity=wishlist&bugidtype=include&chfield=%5BBug%20creation%5D&chfieldfrom=2008-01-01&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=bug_severity&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=plasma&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=plasma&value-1-1-0=crash&value0-0-0=&votes= feature requests]
* Template search for all the open reports, since 2008: [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&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&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&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= any kind of report], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&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&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&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= crashes], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&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&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&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= normal bugs], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&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&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&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= feature requests]
 
=Workflow of the bug triaging activity=
 
Now that you have a list of bug reports, pick one and start working.


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


=Handling reports: What to do with a bug report=
{{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.}}


There are several things that must be checked and "fixed" to make an initial bug report an interesting and useful piece of information for the developers to check.
=== Close bug reports that aren't actionable ===
There are many reasons why a bug report might not be actionable:


{{Note|if at any point you don't really know how to continue, because you don't understand the issue properly, always ask to the developers or related contributors}}
===== 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.


As KDE has too many users, we get a lot of reports about bugs which are already reported (the so named "duplicates"). Before putting any effort in the current report we should check for the main report.
==== 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.


==Identifying duplicates==
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].


There are a lot of ways of identifying duplicate reports depending of the kind of bug.
{{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}}


===General===
==== 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.


* Search for duplicates should be done initially against the same product of the bug report you are triaging: 
If you don't find any related issue, you may need to search in a different product.
==== 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.
{{Tip|You can search on different products at the same time}}


{{Note|Due to the heavy usage of libraries in the KDE software, a bug reported for an application may be being tracked at a library product (example, a bug in Plasma Desktop may be a bug in kdelibs, and therefore being tracked in the "kdelibs" product)}}
==== 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.


[http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#List_of_related_KDE_technologies List of related KDE technologies]
"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.


* You may want to filter out the results by date: you can select a date range since some years (or months ago) to "Now" (today)
; 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.


===For "normal" (non-crash) reports===
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.


# Pick some "keywords" from the current report. This keywords need to explain the inner concept of the bug that was reported (they must represent it).
; Examples of Downstream issues:
# Perform a full search over the same product (read general note), initially on the "general" component.
 Initially, put the keywords in the title, and perform the search (this will only look for the keywords in the title)
* A KDE app crashes because a dependent package is not automatically installed by the user's distro.
# If your search has results on it, check them all, reading the whole description and trying to identify the situation.
* Fonts are really hard to read, but only in certain distros.
# If you don't get any results, you need to go back and:

* Graphical corruption with a Plasma theme downloaded from store.kde.org.
#* Change your keywords (tip: select thesaurus, or similar/related concepts); or
#* Use the keywords in the "Comments" field (so the search will look up in the bug description and comments too)


{{Note|When using more than one word in the "Comments" field you need to select the option "contains all of the words/strings"}}
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.


{{Note|It is sometimes difficult to choose the proper ones, as the way of describing a scene varies from person to person (but we have time)}}
==== 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.


===For "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.


# Perform the same operation as with normal bug reports
==== Move it to the right place ====
# Check for reports with duplicate backtraces: 
 (Read the [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#C.2B.2B_Backtraces_.28identifying_crashes_duplicates.29 Backtraces section] below)
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.


Perform a full search over the same product (read general note), initially on the "general" component, putting the "ClassName::FunctionName" pairs that identify the crash in the Comments field of the form (if you put more than one pair, you need to select the option "contains all of the words/strings")
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.


===Processing search results===
{{Warning|Only reassign the bug report if you're sure it's in the wrong product.}}


* If you don't find any similar report then we should assume the new bug reports is "unique" (and valid). See next section

==== Fix obvious metadata field errors ====
Quickly go through the bug report's metadata; fields like version, platform, severity (the second combobox on the 'importance' row"), 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.


* If you find a similar bug report we have too choices:
{{Note|The "version" field is for reporting the ''latest'' version that the bug has been reproduced against, not the original version.}}
** If you are completely sure it is the same issue, you have to mark the report as duplicate. 

The bug report you initially picked (name it "copy") is going to be marked as duplicate of the original report (name it "main"). If "copy" has additional information that "main" doesn't have, you may want to add it. (Note: some details may look unimportant to you, but they may be important for developers who know about the application workflow and code. Also, adding a big amount of minimal/incomplete information you may end up generating a big and complete testcase)

** If you aren't completely sure: you need someone else to double check your work. You may want to add a comment in the current report. Then, you should ask in #kde-bugs IRC channel for someone to look at your comment.
Comment template:
This bug looks related to bug XXXXXX
(XXXXXX being the bug ID of "master")


{{Note|You may found related reports that are already marked as duplicate of a third report. Always try to use this third report as the "main" one (resolve the duplicates chain). However, in some cases, the "main" reports refers to a root issue, and some of its duplicates may refer to sub-issues. In those cases try to check which one refers to the issue you are looking at.}}
If the correct version or platform is missing from the list, contact the software maintainer or the KDE Bugzilla admins to get this corrected.


==Identifying duplicates (crashes) : C++ Backtraces==
==== 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.


===Definition===
==== Ask for any missing information ====
Now it's time to fill in missing info.


A backtrace is a piece of information that describes what was the application doing when it encountered the error and had to close itself. It is a “function stack” leading to the “crashing point”.
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


In KDE applications, the backtraces are generated by the Crash Handler Dialog (“DrKonqi”). They can also be generated by the general debugger “GDB”, but that involves more steps.
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: [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.


The backtrace is read from top to bottom. The first line shows ''where'' the crash occurred (because of an illegal instruction, invalid pointer, memory problem or other issues). The other lines show the “way to the first function”.
=== 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.


===Example===
==== 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.


Application: Plasma Workspace (kdeinit4), signal: Bus error
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.
[KCrash Handler]
#5  0x00007fb563bb8f02 in KPixmapCache::Private::mmapFile (this=0x92df60,
filename=..., info=0x92dfb0, newsize=33656832) at /usr/src/debug/kdelibs-
4.4.1/kdeui/util/kpixmapcache.cpp:491
#6  0x00007fb563be3c34 in KPixmapCache::Private::mmapFiles (this=0x92df60) at
/usr/src/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:419
#7  0x00007fb563be38e3 in KPixmapCache::Private::init (this=0x92df60) at
/usr/src/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1061
#8  0x00007fb563be576d in KPixmapCache::discard (this=0x1203ca0) at /usr/src
/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1279
#9  0x00007fb563be5e48 in KPixmapCache::deleteCache (name=...) at /usr/src
/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1255
#10 0x00007fb55afdc97d in Plasma::ThemePrivate::discardCache (this=0x7a7d30)
at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:224
#11 0x00007fb55afe009b in Plasma::ThemePrivate::setThemeName (this=0x7a7d30,  
tempThemeName=<value optimized out>, writeSettings=<value optimized out>)
at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:380
#12 0x00007fb55afe19fb in Plasma::Theme::settingsChanged (this=0x70af20) at
/usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:341
#13 0x00007fb55afe2918 in Plasma::ThemePrivate::settingsFileChanged
(this=0x7a7d30, file=<value optimized out>) at /usr/src/debug/kdelibs-
4.4.1/plasma/theme.cpp:335
...


===Description of a backtrace line===
==== 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.


#NumberInTheStack MemoryAddress in Namespace::Class:FunctionMember
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.
(argumentThis=pointerValue, argument1=value, argument2=value, ...) at path/to
/source/code/file.cpp:linenumber


* #NumberInTheStack: is the order number in the function stack. The lesser, the nearer to the crash point. The smaller number may not be zero
==== Set the Severity field ====
* MemoryAddress: we don't put attention to this one.. Ignore
Mark the bug's severity (the second combobox on the 'importance' row) according to these definitions:
* Namespace: C++ namespace of the function. It may not be available if there are no namespaces. This could be also a class name if "Class" is an embedded one.
* Class: C++ class name of the function
* FunctionMember: C++ function name
* argumentThis=pointerValue : this first argument is often the memory address/pointer of the C++ object (example "this=0x91ec5f8"

other argument use the same form "parameterName=parameterValue"
* (..): arguments supplied to the function. This information may not be available if *debug information* is not present


* path/to/source/code/file.cpp:linenumber the path to the source code file that describes that function, and the line number. The path is the one found at '''build time'''. This information may not be useful if '''debug information''' is not available (in that case, the name of the library or application binary may be included. Example: ''/home/kde-devel/kde/lib/libsopranoclient.so.1'')


'''Example''':
{| 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
|}


#13 0xb759d5d7 in Nepomuk::ResourceData::determineUri (this=0x91ec5f8) at
==== Set relevant Keywords ====
/home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp:671
Set whichever keywords from this table are relevant:


* The function is the number 13 in the stack
{| class="wikitable"
* Function's namespace: "Nepomuk"
|-
* Function's class: "ResourceData"
! Keyword !! When to apply it
* Function's function: "determineUri"
|-
* The object "Nepomuk::ResourceData" which called to "determineUri" has the pointer "0x91ec5f8"
| regression || Something that worked in the past, but is now broken
* The function is described (where it was build) at "/home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp". It leads to the next function in the stack at the line number 671
|-
 
| usability || Something that involves a poor user interface or demands a tedious workflow
===Identifying the first (useful) backtrace functions===
|-
 
| 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
The first thing you need to do is to locate where it crashed, identifying the "[KCrash Handler]" mark (only in backtraces fetched using DrKonqi)
|-
 
| wayland || A bug that only manifests on Wayland
If the application only had one thread, then it is at the top of the unique thread; otherwise you may need to look at all the thread (the KCrash mark may not be always in the Thread number 1)
|-
 
| qt6 || A bug that only manifests on software build with Qt 6
Once that you located the "crashing thread start", pickup the first two or three "ClassName::Functions" pairs from top to bottom (some functions should be ignored, read below)
|}
 
This pairs will be used as "keywords" for the duplicate search
 
{{Note|This is only a general rule. There are some special cases when the first three function at the top may be the same but the crash may be different (specially on complex application/libraries as Konqueror)}}
 
If the first backtrace functions aren't available (they are not there, or there are "??") then we can't proceed without [[#Check_the_report_quality_.28and_ask_for_missing_information.29|asking for more information]] (a more complete backtrace).
 
===Avoiding useless function calls===


Some functions or calls are common to a lot of applications using the same core libraries (like the Qt library, glib, glibc, or many others). This kind of functions should not be used for search as they are not representative of the crash itself and it may return lots of results.
==== 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:


'''Classes and functions to ignore in a backtrace''':
* Is readable as a grammatically correct English sentence
* Kernel/GLibC functions (<tt>__kernel_vsyscall</tt>, <tt>raise</tt>, <tt>abort</tt>)
* Contains a brief explanation of the root cause (if it was found)
* Functions from core/base libraries (libraries with filenames like <tt>libpthread.so.0</tt>, <tt>libc.so</tt>, <tt>libstdc++.so</tt>, <tt>libglib-2.0.so</tt>; or functions starting with "*__GI_"). You may also need to ignore calls to graphics drivers (like nvidia or libGL)
* Includes some of the symptoms people are experiencing
* Qt containers classes (<tt>QMap</tt>, <tt>QList</tt>, <tt>QLinkedList</tt>, <tt>QVector</tt>, <tt>QStack</tt>, <tt>QQueue</tt>, <tt>QSet</tt>, <tt>QMap</tt>, <tt>QMultiMap</tt>, <tt>QHash</tt>, <tt>QMultiHash</tt>)
* Includes <tt>ClassName::FunctionName</tt> pairs if the bug describes a crash
* Qt deep core classes (<tt>QApplication</tt>, <tt>QCoreApplication</tt>, <tt>QBasicAtomicInt</tt>, <tt>QBasicAtomicPointer</tt>, <tt>QAtomicInt</tt>, <tt>QAtomicPointer</tt>, <tt>QMetaObject</tt>, <tt>QPointer</tt>, <tt>QWeakPointer</tt>, <tt>QSharedPointer</tt>, <tt>QScopedPointer</tt>, <tt>QMetaCallEvent</tt>)
* Isn't too long
* Qt misc functions (<tt>qt_message_output</tt>, <tt>qt_message</tt>, <tt>qGetPtrHelper</tt>, functions starting with <tt>qt_meta_</tt>)


===Special cases (Advanced)===


There are special crashes related to the X11 graphics server. To identify this crashes you can search for the "XIOError" function name (often on Thread 1). The "[KCrash handler]" mark appears in a secondary thread.
== 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]].


The important things to identify those crashes is recognizing the functions *below* the XIOError call (this is, which functions caused the X11 error).
=== 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/Issue_Reporting#Multiple_issues_in_a_single_Bugzilla_ticket]]). Sample text can be found at https://invent.kde.org/ngraham/canned-responses#reporter-reported-multiple-distinct-issues.


In most of this crashes the functions below "[KCrash handler]" are not important (but they could still be useful to search for duplicates).
=== 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]].


==Bugs caused by external issues (UPSTREAM/DOWNSTREAM)==
=== 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.
Check if the bug is caused by an external plugin/add-on or distribution issue
 
There are several bugs which may be caused by external add-ons. If you are sure this is the case, you should dismiss the report, telling the reporter to file a new bug in a different place.
 
* Applications which use plugins may be easier to affect (like Plasma when using custom Plasmoids/widgets)
 
Distributions can also bring some trouble, specially with packaging.
 
Some problems that may cause bugs are:
* different versions among KDE packages (kdelibs at one version, kdebase at a different one)
* missing plugins (broken packaging) causing crashes or missing features.
 
Also, distribution can include their own add-ons (to bring their own branding or any other special function). If you know KDE software enough you may be able to recognize these unofficial add-ons.
 
If the reporter mentions an application or dialog you cannot identify, you could try requesting a screenshot; other people may identify if it is a KDE application or an external addition.
 
{{Note|The '''UPSTREAM''' resolution refers to bugs caused by libraries/dependencies, upstream in the software stack (like Qt, glibc, X11).
The '''DOWNSTREAM''' resolution refers to bug caused by the Distributions (broken packaging, ...) or by external plugins (unofficial Plasma widgets, other extensions, ...)}}
 
==Check the report quality (and ask for missing information)==
 
Now that you know that the bug report is unique, and that is not an external issue,  you need to check all the needed information is there.
 
* Check that report is English and that is easily understandable.


** If it is not in English you may want to look for someone on the KDE group (IRC channels) that may translate it for you. Alternatively you can ask the reporter to use some online translation system (you won't get a clear explanation, but it is something).
** 

If the explanation is not clear enough, and you think that the bug could be described in a image, you may want to ask for a screenshot [explanation of Bugzilla attachments]
 
* If the bug is a graphical glitch or issue, you may want to request a screenshot [explanation of Bugzilla attachments]
* If the issue involves any other component (like the graphics card or drivers) you may need to ask for the versions and component's names
* If the bug report is about a crash and the backtrace information is not really complete (and you couldn't perform a duplicate search) you need to ask the user to install the missing debug package symbols, reproduce the bug and generate a new backtrace. Template for this request:
If you can reproduce the crash at will (or you experience this regularly),
can you install the "PACKAGENAME" package and post a complete backtrace here?
(you can get more information at http://techbase.kde.org/User:DarioAndres
/Basic_Guide_about_Crash_Reporting ) Thanks
 
The names of the missing packages depends of the application and the distribution (as package naming scheme changes..). Look at List of debug package names on several Distributions
 
'''Useful information which could be also missing''':
* Application version
* KDE Platform (and/or Software Compilation) version
* If the bug is about a crash, request the version of the Qt library
* If the reporter is using an development version, request the Git or SVN revision of the KDE platform and application
 
{{Note|If you don't get feedback after a period of time, you can mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" (or resolution "BACKTRACE" if you are waiting for a complete backtrace)}}
 
==Setting Bugzilla fields (and re-assignation)==
 
Often the bug reports aren't properly categorized, or they miss some information in the Bugzilla fields (which are useful for sorting and filtering):
 
* '''Version''': 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, and of course the other information in the bug (backtrace, description) should also reflect that same version. In the process of triaging old bug reports the version field is a good indicator for a bug that needs newer information.
** If the version is missing in the list, please contact the software maintainer or the KDE bugzilla admins to add the version in the system.
* '''Priority''': we don't use this field in the KDE bug tracker. The priority is used by the developers to organize their work, it should stay at normal and only changed by the developers of the project.
* '''Severity''': If you are not really sure if a report describes a real bug or a feature; or if you cannot diagnose the issue, you need to ask in the support channels or wait for other triagers or developers to check the report.
** some hints about the various severity options:
*** Critical: The software causes you to lose data.
*** Grave: The software is basically unusable now.
*** Major: A major feature is broken.
*** Crash: The software crashes or hangs.
*** Normal: It's a bug that should be fixed.
*** Minor: minor loss of function, and there is an easy workaround.
*** Wishlist: Request for a new feature or enhancement.
* '''Platform''': this field is only important if the bug is related to one distribution or specific system. (most of the bug reports are common to most of the platforms). Same with the OS field
 
===Renaming a report: Updating the summary===
 
Most of the times, the reporter user initially sets the bug report's title, and therefore, the summary doesn't really represent the bug itself. You may want to update the title to contain enough information to identify the issue properly.
 
A good title may contain:
 
* A brief explanation of the root cause (if it was found)
* Some of the symptoms people are experiencing
* Additional comments between round brackets/parentheses
 
{{Tip|Try to use complete and easily readable english sentences as summary}}
 
* If the bug is about a crash, you may add the first useful ClassName::FunctionName pairs that identify it. You can put them inside square brackets at the end of the title
 
* If the report has additional information (like a testcase file, or an attached proposed patch) you may add those references as tags at the start of the summary (inside square brackets)
 
'''Examples''':
 
[patch] Plasma clock draws garbage when hovering it if the Ctrl key is pressed
 
Dolphin hangs when trying to view the properties of a big file
 
[testcase file] Plasma crashes when adding a special file to the panel
[Class1::Function1, Class1::Function2, Class2::Function3]
 
Applications that use Plasma themes crash when compositing is switched on/off
due an error in KPixmapCache [KPixmapCache::Private::mmapFile,
KPixmapCache::Private::init, KPixmapCache::discard]
 
[testcase url] Konqueror shows a graphical artifact in webpage's form when
scrolling
 
===Reassigning bug reports===
 
Some of the reports are assigned to the wrong product. This may happen because the original reporter didn't know to which application/library did the bug belong to. It may happen if the Crash Handler dialog reports a crash about an unsupported application (or one that is not mapped properly)
 
{{Warning|Only perform re-assignations if you are sure the bug is in the wrong product.}}
 
{{Note|Remember to check the [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#List_of_related_KDE_technologies KDE related technologies list]}}
 
# Select the correct Bugzilla product.
# If you are sure the current assignee is the default of the current product, you need to click the checkbox to reset the assignee (so the assignee of the new(and correct) Bugzilla product will get notified)
# Commit the changes
# In the next page, select the correct Component and Version, and save the changes
 
==Adding related people to the CC list==
 
Sometimes, the reports describe general issues or are filed against common bugzilla products (like "kde" or "kdelibs"); or, on the other round, are filed against specific products (but the underling bug root cause is at some specific library, not directly related to the current bugzilla product assignee)
 
In both cases, if we don't need/want to reassign the report (because we aren't really sure about it), we can add the assignee of the other related products, or other developers mail address, to the CC list of the bug report.
That means, this person (or people following a mailing list) will get notified about this bug report, and they might look at it.
 
To know whom to add to the CC list you can:
* Look at the [https://bugs.kde.org/editproducts.cgi list of bugzilla products and components] and find the current default assignee (this requires special "editcomponents" permissions)
* Look at copyright of the source code related to the bug. (You can always access the code using [http://websvn.kde.org/trunk/KDE/ WebSVN])
* Ask in the IRC support channels which person is related to an specific KDE area (#kde-devel)
 
Common situation '''examples''':
 
* A report against "Dolphin" describes a Nepomuk-related error.
** Add the Nepomuk default assignee to the CC list
 
* A report against "Plasma" describes an error which seems to be more general (at kdelibs level), but you are not really sure if you should reassign it.
** Do not reassign and add "kdelibs-bugs___at___kde___dot___org" to the CC list
 
* A report against the "kde" bugzilla product describes a Konqueror-related issue (and you aren't sure it is a Konqueror-only issue)
** Do not reassign and add "konq-bugs___at___kde___dot___org" to the CC list
 
* A report against the "kde" bugzilla product describes a Plasma issue
** Reassign the report to the "plasma" bugzilla product; or
** Add "plasma-bugs___at___kde___dot___org" to the CC list
 
==Other Situations and Cases==
 
===One report per issue===
 
There is a policy in KDE bugtracker which establishes that different issues/bugs should not be mixed up in the same bug report, in order to keep the database clean and easy to read.
 
If any user adds information which is unrelated to the current bug report, gently tell him/her to write it down on a *different/new report. (The new issue described may be already reported somewhere else. In that case, you need to write a reference to the that bug report ID)
 
=Trying to reproduce the bugs=
 
An important step of bug triaging is trying to reproduce the bugs, this means, using the information the reporters added to the bug report to force(recreate, reproduce, repeat) the bug in the application.
 
This is needed in order to differentiate random/race condition bugs of reproducible ones (which may be reproduced by developers too; and they can fix them)
 
{{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 sightly modified) environment. I 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).}}
 
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|It is also important to have an updated KDE SC installation to test bugs.}}
 
==How to test bug reproducibility==
 
# Read the *complete* bug report (including all the attached information). Note that some bits of information may look unrelated; but they could be useful (or not)
# Use the information in the first comment (the original bug description) to try to reproduce the bug in the application.
# If you can reproduce the bug, then go to the next step
#* If you can't reproduce the bug, use the next comment in the report (which may add new information) to try to reproduce.
#* If you can't reproduce with all the comments in a separate way, you may want to try combined situations (a bit of the description of the original bug, plus a bit of the second one) and similar combinations. You often have to use your imagination a bit (hopefully we still have time). Hopefully, you may find a combination that may reproduce the bug all (or most of) the times. Write down the "recipe" (steps to reproduce it), you need to include that data into the report later.
# Now that we have a result, we need to add our information/conclusions to the bug report
 
{{Tip|When trying to reproduce a bug, and if there are more than one piece of information, at first glance, try to identify a *common situation*. (some data or context that is present in all (or most of) the cases). This kind of data may be the key to find out how to reproduce.}}
 
==Adding new information (and requesting feedback)==
 
* In any case, add your KDE SC version and system information. (other kind of configuration data may be useful to: "did you tested it on a clean environment or in your existing configuration ?"  "do you have library X installed and updated ?" "is your system 32 or 64 bits ?")
 
'''If you could reproduce the bug''':
* If you had to combine several steps to make your own "recipe" to reproduce, write it down. This kind of information should be 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 (of course, if it is not attached already)
 
A template of a comment for this situation could be:
 
I can reproduce the bug here using KDE SC x.y.z, Qt a.b.c on Distribution,
Kernel d.e.f on XX bits.
In order to reproduce I have to perform the following actions:
1- Action 1
2- Action 2
3- Action 3
4- Bug Appears
Note that you need to have the X configuration set to Y, and use the Z library
- Can anyone else confirm this ?
Thanks
 
'''If you could not reproduce the bug''':
* Write down which kind of steps you performed to try to get the bug.
 
* You may want to ask to all the reporters if your step had missing something, or if they notice any other strange (or not-default) situation or configuration which may be related.
 
* Also, if the report is a bit old (more than two major KDE SC releases old), you could try to ask the reporters if you can reproduce the bug in the latest stable KDE SC release or trunk (development version). The bug may be fixed already (but no one wrote it down into the bug report). If a comment indicates that the bug is resolved, close the bug as WORKSFORME, and refer to the comment in which the reporter indicated being unable to reproduce.
 
A template of comment for this situation could be:
 
I couldn't reproduce the bug here using KDE SC x.y.z, Qt a.b.c
on Distribution, Kernel d.e.f on XX bits.
I tried performing this actions:
1- Action 1
2- Action 2
or
1a- Action 1a
2a- Action 2a
However the bug didn't appear/the application didn't crash
- Are you all using library X and this kind of configuration ?
- Can you still reproduce this bug with an updated KDE SC version ?
Thanks
 
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 WORKSFORME (or FIXED)
 
=Getting bug triaging support=
 
During your work you may need help on how to proceed, you can use this resources to get help:
 
* The '''#kde-bugs channel''' on IRC (Freenode.net). You can ask to the whole channel.
* The BugSquad mailing list <bugsquad ##at## kde ##dot## org>
 
=BugWeeks=
 
We are planing to host bug triaging events (where new "students" can learn the tricks) named "BugWeeks" on a regular basis to help cleaning up the KDE bug tracker database.
 
The BugWeeks initiative is based on the Klassroom initiative in the KDE Community Forums
 
You can find more information about this at:
* [http://forum.kde.org/viewtopic.php?f=4&t=84473 BugWeeks announcement]
* [http://forum.kde.org/viewforum.php?f=148 BugWeeks subsection on KDE Community Forums]
* [http://forum.kde.org/viewtopic.php?f=148&t=84713 BugWeek 0 - Plasma Desktop bugs] ([http://forum.kde.org/viewtopic.php?f=148&t=84888 Summary])
 
=FAQ=
=More Information=
 
==List of related KDE technologies==
 
* Every KDE application use kdelibs [Bugzilla product: '''"kdelibs"''']
* Applications using the standard KDE file operations use KIO [Bugzilla product: '''"kio"'''] and probably KFile (for the UI part) [Bugzilla product: '''"kfile"''']
* Oxygen widget style (default) [Bugzilla product: '''"oxygen"''' component '''"style"'''] (I'm adding the component because "Oxygen" also refers to a Plasma and icon themes)
* Multimedia usage: Phonon library [Bugzilla product: '''"Phonon"''']
* PIM related applications use kdepimlibs, Akonadi and kresources technologies [Bugzilla products: '''"kdepim"''', '''"kdepimlibs"''', '''"Akonadi"''', '''"kresources"''']
* Applications using KHTML [Bugzilla product: '''konqueror"''']
* Applications using OpenDesktop services uses Attica [Bugzilla product: '''"attica"''']
* Screen management related operations use the Kephal subsystem [Bugzilla product: '''"kephal"''']
* Games use libkdegames [Bugzilla product: '''"libkdegames"''']
* Scanning related applications probably use the KSane lib [Bugzilla product: '''"libksane"''']
* Multimedia applications reading audio tags use taglib [Bugzilla product: '''"taglib"''']
* Hardware related functions use Solid classes [Bugzilla product: '''"solid"''']
* Power Management functions use PowerDevil [Bugzilla product: '''"solid"''', component: '''"powerdevil-daemon"''']
 
==Special products and cases==
 
* "systemsettings" contain bug reports of the Shell application SystemSettings and kcmshell4, and reports of the configuration modules "kcm_*"
** Try to identificate if the report is about the shell applications (and set the component to "general", "treeview" or "kcmshell") or about some of the configuration modules (and set the component to "kcm_*name*")
 
* Konqueror can use different engines, like KHTML or WebKit
** If the report is about a webkit-only issue, reassign to product "kdelibs", component "kdewebkit"
 
{{Tip|When updating the bugzilla product or component, do not forget to reset to the default assignee}}
 
==Useful Links==
 
* [http://techbase.kde.org/Contribute/Bugsquad BugSquad page on Techbase]
* [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla Quick introduction to Bugzilla]
* [https://darioandreskde.wordpress.com/ Dario_Andres blog about bug triaging]
* [https://bugs.kde.org/page.cgi?id=fields.html A Bug's Life Cycle]
* [http://forum.kde.org/viewtopic.php?f=9&t=84475 Preparing a testing environment]
* [http://techbase.kde.org/Contribute/Bugsquad/How_to_create_useful_crash_reports How to create useful crash reports]
* [http://techbase.kde.org/User:DarioAndres/Basic_Guide_about_Crash_Reporting Basic guide about crash reports]
* [http://aseigo.blogspot.com/2009/01/bugskdeorg.html aseigo's suggestions for bugs.kde.org]
 
==Debug package names for several distributions==
 
For every KDE application it is recommended to install the debug information for "kdelibs" and "qt4"
 
{| class="wikitable" style="border:1px solid #AAA; padding:2px"
|-
!  Package
!  Ubuntu/Debian
!  OpenSuse
!  Fedora
!  Mandriva
|-
|  ''kdelibs''
|  kdelibs5-dbg
|  kdelibs4-debuginfo
|  kdelibs-debuginfo
|  kdelibs4-debug
|-
|  ''qt''
|  libqt4-dbg
|  libqt4-debuginfo
|  qt-debuginfo
|  qt4-debug
|-
|  ''kdebase (KDE base applications)''
|  kdebase-dbg, kdebase-runtime-dbg, kdebase-workspace-dbg
|  kdebase4-debuginfo, kdebase4-runtime-debuginfo, kdebase4-workspace-debuginfo
|  kdebase-debuginfo, kdebase-runtime-debuginfo, kdebase-workspace-debuginfo
|  kdebase4-debug, kdebase4-runtime-debug, kdebase4-workspace-debug
|-
|  ''General example for every KDE "MODULE"''
|  kdeMODULE-dbg
|  kdeMODULE4-debuginfo
|  kdeMODULE-debuginfo
|  kdeMODULE4-debug
|-
|  ''Phonon (multimedia subsystem)''
|  phonon-dbg
|  libphonon4-debuginfo / phonon4-debuginfo
|  phonon-debuginfo
|  phonon-debug
|}


For a detailed list of distributions naming scheme examples you can look at [http://techbase.kde.org/index.php?title=User:DarioAndres/CreateUsefulReports#How_to_obtain_debug_package_for_several_distributions How to obtain debug packages for every distribution].
=== 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.


==Glossary==


* Testcase: custom file that triggers a bug in the application. A testcase can also be a custom code snippet, or to a set of steps.
== Bug Janitor ==
KDE bug reports are overseen by a basic [https://invent.kde.org/sysadmin/bugzilla-bot 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

Latest revision as of 21:56, 7 August 2024

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 (the second combobox on the 'importance' row"), 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 (the second combobox on the 'importance' row) 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/Issue_Reporting#Multiple_issues_in_a_single_Bugzilla_ticket). Sample text can be found at https://invent.kde.org/ngraham/canned-responses#reporter-reported-multiple-distinct-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
Retrieved from "https://community.kde.org/index.php?title=Guidelines_and_HOWTOs/Bug_triaging&oldid=101190"