Guidelines and HOWTOs/Bug triaging: Difference between revisions

From KDE Community Wiki
(Fix typos)
(First crack at a rewrite, for improved approachability and relevance)
Line 1: Line 1:
[[File:Mascot konqi-support-bughunt.png|thumbnail|right|Help [[Konqi]] catch some bugs!]]
[[File:Mascot konqi-support-bughunt.png|thumbnail|right|Help [[Konqi]] catch some bugs!]]
KDE bug triagers verify that Bugzilla tickets describe real bugs, are accurate and reproducible and that the reporter has given enough information. The goal is to save developers from doing this work, which helps them fix bugs more quickly and do more work on their software''
KDE bug triagers verify that Bugzilla tickets describe real bugs, are accurate and reproducible, and that the reporter has given enough information. The goal is to save developers from doing this work, which helps them fix bugs more quickly and do more work on KDE software.


You do not need any programming knowledge to be a bug triager, but experience has shown that members of this team often learn a lot in the course of dealing with bug reports, and many moves on to developing the software itself. If you are just starting to learn programming, it's a great way to gain familiarity with the components and give practical support to the KDE community.  
You don't need any programming knowledge to be a bug triager, but experience has shown that members of this team often learn a lot in the course of dealing with bug reports, and many move on to developing the software itself. If you are just starting to learn programming, it's a great way to gain familiarity with the components and give practical support to the KDE community.


=Getting started=
The sheer number of open bugs can be overwhelming at the start. Here are some hints on getting started more smoothly:
* Look at a single product at a time. For large applications (like Konqueror), you may want to further limit your search to a particular component.
* Don't try to find duplicates early on. Finding duplicates is hard until you have become familiar with the bugs in a component. Start out with verifying UNCONFIRMED bugs as described above. That's valuable work, and a great way to familiarize yourself with the bug database.
* Avoid very old bugs with many comments, and also bugs with many votes. This may seem counter-intuitive, but in most cases these bugs are hard, have gotten a lot of attention, and are probably on a developer's TODO list already. If it is from an older version of KDE, and there are no recent comments, verify them, make a notation, and move on.
* Don't be afraid to ask the reporter for more info. It's something you can even do without Bugzilla permissions. And reporters will generally prefer being asked one question too many, instead of their report never being dealt with. Just remember to be polite. Ask yourself how you would feel if you got the message you are thinking about sending to a user.
* Look at the incoming Bugzilla bugs. Or find the oldest bugs for your favorite software application.
* Look through the rest of our documentation for more information!
=General Considerations=
* '''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.
* Don't try to do too many things at the same time - you will end up with a headache!


= 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 often more impatcful than being right. If you need to request information or feedback, be clear and polite and you will get more information in less time.
* 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]
* 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]


* 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]
=Trying to reproduce the bugs=
An important step of bug triaging is trying to reproduce the bugs. This means that you use the information provided by the reporter and try to make the bug manifest in your own system.
{{Warning|Testing bug reports may modify/alter your own desktop configuration; also, to try to reproduce some bugs you may need a clean pristine (or slightly modified) environment. We recommend you to perform tests on a separate KDE installation or a clean user. There is also a way to start KDE applications with a clean configuration, even under your current configuration (setting the KDEDIR environment variable at run-time to an empty directory).}}
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 up-to-date KDE components installed 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 might be useful
# Usually you will try to reproduce the bug based on the description, but sometimes the comments provide updated reproduction steps, so it makes sense to scan them before you start
# If you can reproduce the bug, go to the next step
#* If you can't reproduce with any scenario mentioned in the comments, you may want to try combined situations (a bit of the description of the original bug, plus a bit of the second one). Hopefully, you will find a combination that reproduces the bug reliably. Note down the newly found steps to reproduce so you can Include them in your comment
# Now that we have a result, we need to add our information/conclusions to the bug report
{{Tip|When faced with a report containing scattered pieces of information, 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 finding out the reproduction steps.}}
==Adding new information (and requesting feedback)==
* In any case, add the versions of your KDE components and your system information. Other kinds of configuration data might also be useful: "did you test it on a clean environment or in your existing configuration?"  "do you have library X installed and updated ?" "is your system 32- or 64-bit ?"
'''If you could reproduce the bug''':
* If you had to combine several steps to make your own "recipe" to reproduce, write them down. This kind of information is useful for the developers.
* If you had to use custom input data (text, or a file), you may want to attach it to the bug report
A template for a comment in this situation could be:
I can reproduce the bug here using KDE Frameworks x.y.z, Qt a.b.c on Distribution,
XX-bit Kernel d.e.f.
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?
'''If you could not reproduce the bug''':
* Write down the steps you performed to try to see the bug
* You may want to ask, if your steps missed something, or if anyone notices any other strange (or non-default) situation or configuration which may be related
* Also, if the report is several months old, you could try to ask the reporter if they can reproduce the bug in the latest stable KDE components releases or trunk (development version). The bug may be fixed already (but no one mentioned it in 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 for a comment in this situation could be:
I couldn't reproduce the bug here using KDE Frameworks x.y.z, Qt a.b.c
on Distribution, XX-bit Kernel d.e.f.
I tried performing these 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 configuration?
Can you still reproduce this bug with updated KDE Frameworks?
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).


=Get permission to work on the bug tracker=
= Getting started =
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 mess things up (and consume the developers' or other triager's time) the tracker requires special permissions to perform changes in the fields of bug reports.
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 mess things up (and consume the developers' or other triager's time) the tracker requires special permissions to perform changes in the fields of bug reports.


If you want to be able to change the field data in bug reports, you need to prove that you know what you are doing. Some examples of this proof are prior helpful comments and triaging action on KDE bugs, prior experience triaging bugs in a professional setting. To request access, ask in the '''#kde-bugs''' [[Internet Relay Chat | IRC channel]].
If you want to be able to change the field data in bug reports, you need to prove that you know what you are doing. Some examples of this proof are prior helpful comments and triaging action on KDE bugs, prior experience triaging bugs in a professional setting. To request access, ask in the '''#kde-bugs''' [[Internet Relay Chat | IRC channel]].


{{Note|every user is allowed to add comments in any bug report; this can mark the start of your bug triaging!}}
=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 wishlist 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:'''
= Decide what to work on =
* You don't focus on one product
== Today's bug reports ==
* 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)
 
===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 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 '''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]
Line 135: Line 23:
* All the '''feature requests''' reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]
* All 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==
== All bug reports of a single product ==
 
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 beginning (like 2000)).
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 beginning (like 2000)).


This technique is useful to audit old bugs or perform a deep clean (in case the bugs weren't triaged on a daily basis previously).
This technique is useful to audit old bugs or perform a deep clean (in case 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
'''Not so Good:'''
* The reports of the other applications 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).
===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 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]
* 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.
= What to do with bug reports =
Now that you have a list of bug reports, pick one and start working! Here is the optimal bug triaging workflow:


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


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


{{Note|if at any point you don't really know how to continue, because you don't understand the issue properly, always ask the developers or related contributors}}
{{Note|if at any point you aren't sure how to proceed, move onto the next bug or ask a KDE developers or other more experienced contributor}}


As KDE has so many users, we get a lot of reports about bugs which are already reported (duplicates). Before putting any effort in the current report we should check for an existing report.


==Identifying duplicates==
== Identify duplicates ==
As KDE has so many users, we get a lot of reports about bugs which have already been reported (duplicates). Before putting any effort in the current report, check for an existing report. If you find a pre-existing bug report describing the same issue, mark this one as a duplicate of it.


Please see [[Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates|the article on identifying duplicates]].
Please see [[Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates|the article on identifying duplicates]].


==Bugs caused by external issues (UPSTREAM/DOWNSTREAM)==
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, especially with packaging.


Some problems that may cause bugs are:
== Identify bugs caused by external issues (UPSTREAM/DOWNSTREAM) ==
* different versions of KDE packages (kdelibs at one version, kdebase at a different one)
If you imagine software as a river, then software KDE uses that comes from others (e.g. Qt, X11, the Linux kernel) is '''UPSTREAM''' of KDE, and others who make use of KDE software  (e.g Linux distributions, 3rd party Plasma plugins) are '''DOWNSTREAM''' of KDE.
* missing plugins (broken packaging) causing crashes or missing features.


Also, distributions 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.
Not all real bugs affecting KDE software are caused by a fault in KDE software.


If the reporter mentions an application or dialog you cannot identify, you could try requesting a screenshot. Other people may be able to recognize an external add-on.
Examples of upstream issues:
* KDE app crashes in QtQuick
* KDE app experiences an issue, but only when using the proprietary NVIDIA driver


{{Note|The '''UPSTREAM''' resolution refers to bugs caused by libraries/dependencies, upstream in the software stack (like Qt, glibc, X11).
Examples of downstream issues:
The '''DOWNSTREAM''' resolution refers to bug caused by the Distributions (broken packaging, ...) or by external plugins (unofficial Plasma widgets, other extensions, ...)}}
* A KDE app crashes because a dependent package is not automatically installed in distro X, Y, or Z
* Fonts are really hard to read, but only in distro X, Y, or Z
* Graphical corruption with a Plasma theme downloaded from store.kde.org


==Check the report quality (and ask for missing information)==


== Ask for any missing information ==
Now that you know that the bug report is unique and that it is not an external issue, you need to check that all the needed information is there.
Now that you know that the bug report is unique and that it is not an external issue, you need to check that all the needed information is there.


* Check that report is in English and that is easily understandable.

* If the description is not written in English and you cannot understand it, you may want to ask other KDE contributors to translate it for you. Alternatively, you can ask the reporter to use some online translation system (you won't get a clear explanation, but it is something).
** If it is not in English you may want to look for someone in 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 an image, you may want to ask for a screenshot
* If the bug is a graphical glitch or issue, you may want to request a screenshot
* If the issue involves any other component (like the graphics card or drivers), you may need to ask for the versions and component 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 symbols package, 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 depend on the application and the distribution (as package naming schemes change). Look at the list of debug package names in several Distributions at the end of this article.
* If the reporter has not indicated what versions of KDE Plasma, Qt, and KDE Frameworks they are using, and this information seems necessary to triage the bug report, ask them to provide that information and remind them about https://community.kde.org/Get_Involved/Bug_Reporting#Software_versions


'''Useful information which could be also missing''':
* If the explanation is not clear enough, ask for clarification and concrete Steps to Reproduce, and remind them about https://community.kde.org/Get_Involved/Bug_Reporting#Steps_to_Reproduce
* Application version
* KDE Frameworks version
* Qt library version
* If the reporter is using a development version, request the Git or SVN revision of the KDE Frameworks and application


{{Note|Feel free to mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" after asking for further information (or resolution "BACKTRACE" if you are waiting for a complete backtrace)}}
* If the issue is hard to picture without a visual aid and there are no screenshots attached, ask for one--or better yet, a screen recording--and remind them about https://community.kde.org/Get_Involved/Bug_Reporting#Screenshots_and_screen_recordings


==Setting Bugzilla fields (and reassignation)==
* If the bug report is about a crash and the backtrace information is not really complete (and you couldn't perform a duplicate search), ask the user to install the missing debug symbols package, reproduce the bug, and generate a new backtrace. Point them to [Guidelines and HOWTOs/Debugging/How to create useful crash reports]


Often the bug reports aren't properly categorized, or they miss some information in the Bugzilla fields (which are useful for sorting and filtering):
{{Note| After asking for further information, mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" (or resolution "BACKTRACE" if you are waiting for a complete backtrace)}}


* '''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 of 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 be 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 a 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===
== Reproduce the bug ==
At this point, the bug report enough is complete enough that you should use the information provided by the reporter and try to make the bug appear on your own system.


Most of the time the reporter sets the bug report's summary and therefore it might not accurately represent the bug. You may want to update the summary to contain enough information to identify the issue properly.
{{Note|It is important to have up-to-date KDE components installed to test bugs. Only try to reproduce bugs using the latest versions of KDE software, or even development versions}}


A good summary may contain:
{{Warning|Testing bug reports may modify/alter your own desktop configuration; also, to try to reproduce some bugs you may need a clean pristine (or slightly modified) environment. We recommend you to perform tests on a separate KDE installation or a clean user. There is also a way to start KDE applications with a clean configuration, even under your current configuration (setting the KDEDIR environment variable at run-time to an empty directory).}}


* A brief explanation of the root cause (if it was found)
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]
* Some of the symptoms people are experiencing
* Additional comments in brackets/parentheses


{{Tip|Try to use complete and easily readable English sentences as the summary}}
If you can't reproduce with any scenario mentioned in the comments, you may want to try other related situations. Hopefully you will find a combination that reproduces the bug reliably. Write down any newly discovered steps to reproduce.


* 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)
=== If you cannot reproduce the bug under any circumstances ===
Write down the steps you performed. You may want to ask the reporter if your steps missed something, or if anyone notices any other strange or non-default situation or configuration which may be related.


'''Examples''':
Hopefully, you will get feedback from the reporters and you could gather more information to try to reproduce the bug or close the report as RESOLVED WORKSFORME (or FIXED). Time to move onto the next bug!


[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
=== If you can reproduce the bug ===
If you had to combine several steps to make your own "recipe" to reproduce, write them down. This kind of information is useful for the developers. If you had to use custom input data (text, or a file), you may want to attach it to the bug report. And mention the environment and circumstances under which you can reproduce the bug.


[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
== Set Bugzilla fields ==
due an error in KPixmapCache [KPixmapCache::Private::mmapFile,
Often a bug report isn't properly categorized, or lacks some information in the Bugzilla fields (which are useful for sorting and filtering). If a field isn't mentioned below, you don't need to change it.
KPixmapCache::Private::init, KPixmapCache::discard]


[testcase url] Konqueror shows a graphical artefact in webpage's form when
=== Version===
scrolling
If the report has an application version, you need to set the version in the Bugzilla field. Ideally the version field should reflect the latest version the bug is reproducible with. If the version is missing in the list, please contact the software maintainer or the KDE Bugzilla admins to add the version.


===Reassigning bug reports===
=== Severity ===
Mark the bug's severity. Some hints about the various severity options:
* '''Critical''': A widespread, easily reproducible issue that causes data loss
* '''Grave''': The software is basically unusable, with no workaround
* '''Major''': A major feature is broken, and the workaround (if any) is painful and difficult
* '''Crash''': The software crashes or hangs
* '''Normal''': It's a bug that should be fixed, possibly with a reasonable workaround.
* '''Minor''': Minor cosmetic issue or loss of function with an easy workaround.
* '''Wishlist''': Request for a new feature or enhancement.


Some of the reports are assigned to the wrong product. This may happen because the original reporter didn't know which application/library the bug belongs to. It may happen if the Crash Handler dialog reports a crash about an unsupported application (or one that is not mapped properly)
=== Platform  ===
This field is only important if the bug is related to one distribution or a specific system (most of the bug reports are common to most of the platforms).


{{Warning|Only perform reassignations if you are sure the bug is in the wrong product.}}
=== Keywords ===
If the bug seems like it would be really easy to fix, add the "junior-jobs" keyword. Examples of issues that would be easy to fix:
* Inaccurate description or text label
* Visual layout inconsistencies
* Pixellated icons when an app is run in HiDPI mode
* User interface element is the wrong color when using Breeze Dark


{{Note|Remember to check the [[Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates#List_of_related_KDE_technologies|KDE related technologies list]]}}
New code contributors often start with "junior-jobs"" bugs, so ensuring that there is a steady supply of bugs tagged with this keyword helps them get started with small, manageable tasks.


# Select the correct Bugzilla product.
If the bug involves a poor user interface or demands a tedious workflow, tag it with the "usability" keyword, and it will be considered a part of KDE's [https://phabricator.kde.org/T6831|"Usability & productivity" initiative].
# If you are sure the current assignee is the default for the current product, you need to click the checkbox to reset the assignee (so the assignee of the new Bugzilla product will get notified)
# Save the changes
# In the next page, select the correct Component and Version and save the changes


==Adding related people to the CC list==
=== Status ===
Set the bug status to CONFIRMED if you can confirm it.


Sometimes the reports describe general issues or are filed against common Bugzilla products (like "kde" or "kdelibs"). Conversely, they might be filed against specific products, but the underling root cause is in 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, we can add the assignee of the other related products, or other developer's mail address, to the CC list of the bug report.
== Rename the bug report, if necessary ==
This person (or people following a mailing list) will then get notified about this bug report and they might look at it.
The bug report's summary might not accurately represent the bug, especially after you have triaged the bug and found the root cause or determined it to be another issue. You may want to update the summary to contain enough information to identify the issue properly. A good summary:


To know who to add to the CC list you can:
* Is readable as a grammatically correct English sentence
* 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)
* Contains a brief explanation of the root cause (if it was found)
* Look at the copyright of the source code related to the bug. You can always access the code using [https://websvn.kde.org/trunk/ WebSVN]
* Includes some of the symptoms people are experiencing
* Ask in the IRC support channels, if anyone knows which person is related to a specific KDE area (#kde-devel)
* Includes <tt>ClassName::FunctionName</tt> pairs if the bug describes a crash
* Isn't too long


Common situation '''examples''':


* A report against "Dolphin" describes a Baloo-related error.  
== Reassign the bug report to a different Product, if necessary ==
** Add the Baloo default assignee to the CC list
Many bug reports are reported against the wrong product. This may happen because the original reporter didn't know which application/library the bug belongs to. For example, many bugs filed to Dolphin are actually about KIO (the I/O framework) or Baloo (the search frameworks). Remember to check the [[Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates#List_of_related_KDE_technologies|KDE related technologies list]]


* 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.
{{Warning|Only perform reassignations if you are sure the bug is in the wrong product.}}
** 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 are not 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 the KDE bug tracker which establishes that different issues should not be mixed up in the same 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 them to write it down in a different/new report. The new issue described may be already reported somewhere else. In that case, you need to include a reference to that bug report ID.


=Getting bug triaging support=


During your work, you may need help on how to proceed. You can use these resources to get help:
= Special circumstances =


* The '''#kde-bugs channel''' on IRC (Freenode.net). You can ask the whole channel.
== Bug describes multiple issues ==
* The BugSquad mailing list <bugsquad ##at## kde ##dot## org>
You must close the bug report as RESOLVED INVALID with a '''humane''' explanation that bug reports can only contain a single issue. Reming the reporter about https://community.kde.org/Get_Involved/Bug_Reporting#Step_6:_File_a_high-quality_bug_report


=More Information=
== Bug includes a patch ==
If the bug reporter or someone else included a patch, direct them to submit it using Phabricator, and remind them about https://community.kde.org/Get_Involved/Bug_Reporting#Submit_patches_using_Phabricator.2C_not_the_bug_tracker


==Special products and cases==
== 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


* "systemsettings" contain bug reports for the Shell application SystemSettings and kcmshell4 and reports for the configuration modules "kcm_*"
== Same person reports a lot of bugs ==
** Try to find out, 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*")
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.


* 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 =
 
==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://darioandreskde.wordpress.com/ Dario_Andres blog about bug triaging]
* [https://bugs.kde.org/page.cgi?id=fields.html A Bug's Life Cycle]
* [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://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]
* [Guidelines and HOWTOs/Debugging/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]
* [http://aseigo.blogspot.com/2009/01/bugskdeorg.html aseigo's suggestions for bugs.kde.org]
==Glossary==
* Testcase: custom file that triggers a bug in the application. A testcase can also be a custom code snippet or a set of steps.

Revision as of 04:44, 21 February 2018

Help Konqi catch some bugs!

KDE bug triagers verify that Bugzilla tickets describe real bugs, are accurate and reproducible, and that the reporter has given enough information. The goal is to save developers from doing this work, which helps them fix bugs more quickly and do more work on KDE software.

You don't need any programming knowledge to be a bug triager, but experience has shown that members of this team often learn a lot in the course of dealing with bug reports, and many move on to developing the software itself. If you are just starting to learn programming, it's a great way to gain familiarity with the components and give practical support to the KDE community.


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 often more impatcful than being right. If you need to request information or feedback, be clear and polite and you will get more information in less time.
  • If you are not familiar with the Bugzilla (KDE bug tracker system) interface, you may find this guide useful: Quick Introduction to Bugzilla


Getting started

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 mess things up (and consume the developers' or other triager's time) the tracker requires special permissions to perform changes in the fields of bug reports.

If you want to be able to change the field data in bug reports, you need to prove that you know what you are doing. Some examples of this proof are prior helpful comments and triaging action on KDE bugs, prior experience triaging bugs in a professional setting. To request access, ask in the #kde-bugs IRC channel.


Decide what to work on

Today's bug reports

All bug reports of a single product

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 beginning (like 2000)).

This technique is useful to audit old bugs or perform a deep clean (in case the bugs weren't triaged on a daily basis previously).


What to do with bug reports

Now that you have a list of bug reports, pick one and start working! Here is the optimal bug triaging workflow:

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.

Note

if at any point you aren't sure how to proceed, move onto the next bug or ask a KDE developers or other more experienced contributor


Identify duplicates

As KDE has so many users, we get a lot of reports about bugs which have already been reported (duplicates). Before putting any effort in the current report, check for an existing report. If you find a pre-existing bug report describing the same issue, mark this one as a duplicate of it.

Please see the article on identifying duplicates.


Identify bugs caused by external issues (UPSTREAM/DOWNSTREAM)

If you imagine software as a river, then software KDE uses that comes from others (e.g. Qt, X11, the Linux kernel) is UPSTREAM of KDE, and others who make use of KDE software (e.g Linux distributions, 3rd party Plasma plugins) are DOWNSTREAM of KDE.

Not all real bugs affecting KDE software are caused by a fault in KDE software.

Examples of upstream issues:

  • KDE app crashes in QtQuick
  • KDE app experiences an issue, but only when using the proprietary NVIDIA driver

Examples of downstream issues:

  • A KDE app crashes because a dependent package is not automatically installed in distro X, Y, or Z
  • Fonts are really hard to read, but only in distro X, Y, or Z
  • Graphical corruption with a Plasma theme downloaded from store.kde.org


Ask for any missing information

Now that you know that the bug report is unique and that it is not an external issue, you need to check that all the needed information is there.

  • If the description is not written in English and you cannot understand it, you may want to ask other KDE contributors to translate it for you. Alternatively, you can ask the reporter to use some online translation system (you won't get a clear explanation, but it is something).
  • If the bug report is about a crash and the backtrace information is not really complete (and you couldn't perform a duplicate search), ask the user to install the missing debug symbols package, reproduce the bug, and generate a new backtrace. Point them to [Guidelines and HOWTOs/Debugging/How to create useful crash reports]

Note

After asking for further information, mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" (or resolution "BACKTRACE" if you are waiting for a complete backtrace)


Reproduce the bug

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

Note

It is important to have up-to-date KDE components installed to test bugs. Only try to reproduce bugs using the latest versions of KDE software, or even development versions


Warning

Testing bug reports may modify/alter your own desktop configuration; also, to try to reproduce some bugs you may need a clean pristine (or slightly modified) environment. We recommend you to perform tests on a separate KDE installation or a clean user. There is also a way to start KDE applications with a clean configuration, even under your current configuration (setting the KDEDIR environment variable at run-time to an empty directory).


You may want to use this reference text to setup your testing environment: Preparing a testing environment

If you can't reproduce with any scenario mentioned in the comments, you may want to try other related situations. Hopefully you will find a combination that reproduces the bug reliably. Write down any newly discovered steps to reproduce.


If you cannot reproduce the bug under any circumstances

Write down the steps you performed. You may want to ask the reporter if your steps missed something, or if anyone notices any other strange or non-default situation or configuration which may be related.

Hopefully, you will get feedback from the reporters and you could gather more information to try to reproduce the bug or close the report as RESOLVED WORKSFORME (or FIXED). Time to move onto the next bug!


If you can reproduce the bug

If you had to combine several steps to make your own "recipe" to reproduce, write them down. This kind of information is useful for the developers. If you had to use custom input data (text, or a file), you may want to attach it to the bug report. And mention the environment and circumstances under which you can reproduce the bug.


Set Bugzilla fields

Often a bug report isn't properly categorized, or lacks some information in the Bugzilla fields (which are useful for sorting and filtering). If a field isn't mentioned below, you don't need to change it.

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. If the version is missing in the list, please contact the software maintainer or the KDE Bugzilla admins to add the version.

Severity

Mark the bug's severity. Some hints about the various severity options:

  • Critical: A widespread, easily reproducible issue that causes data loss
  • Grave: The software is basically unusable, with no workaround
  • Major: A major feature is broken, and the workaround (if any) is painful and difficult
  • Crash: The software crashes or hangs
  • Normal: It's a bug that should be fixed, possibly with a reasonable workaround.
  • Minor: Minor cosmetic issue or loss of function with an easy workaround.
  • Wishlist: Request for a new feature or enhancement.

Platform

This field is only important if the bug is related to one distribution or a specific system (most of the bug reports are common to most of the platforms).

Keywords

If the bug seems like it would be really easy to fix, add the "junior-jobs" keyword. Examples of issues that would be easy to fix:

  • Inaccurate description or text label
  • Visual layout inconsistencies
  • Pixellated icons when an app is run in HiDPI mode
  • User interface element is the wrong color when using Breeze Dark

New code contributors often start with "junior-jobs"" bugs, so ensuring that there is a steady supply of bugs tagged with this keyword helps them get started with small, manageable tasks.

If the bug involves a poor user interface or demands a tedious workflow, tag it with the "usability" keyword, and it will be considered a part of KDE's "Usability & productivity" initiative.

Status

Set the bug status to CONFIRMED if you can confirm it.


Rename the bug report, if necessary

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

  • 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


Reassign the bug report to a different Product, if necessary

Many bug reports are reported against the wrong product. This may happen because the original reporter didn't know which application/library the bug belongs to. For example, many bugs filed to Dolphin are actually about KIO (the I/O framework) or Baloo (the search frameworks). Remember to check the KDE related technologies list

Warning

Only perform reassignations if you are sure the bug is in the wrong product.


Special circumstances

Bug describes multiple issues

You must close the bug report as RESOLVED INVALID with a humane explanation that bug reports can only contain a single issue. Reming the reporter about https://community.kde.org/Get_Involved/Bug_Reporting#Step_6:_File_a_high-quality_bug_report

Bug includes a patch

If the bug reporter or someone else included a patch, direct them to submit it using Phabricator, and remind them about https://community.kde.org/Get_Involved/Bug_Reporting#Submit_patches_using_Phabricator.2C_not_the_bug_tracker

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.


Useful Links

Retrieved from "https://community.kde.org/index.php?title=Guidelines_and_HOWTOs/Bug_triaging&oldid=79508"