The KDE Bugsquad keeps track of incoming bugs in KDE software, and goes through old bugs. We verify that a bug exists, whether it is reproducible, and that the reporter has given enough information. Our goal is to save developers from doing this, which helps them fix bugs more quickly and do more work on KDE software.
Getting involved in the Bugsquad is a good place to start. An existing member will help you out and mentor you. One of the great things about the Bugsquad and bug triaging is that you do not need any programming knowledge! That said, experience has shown that members of this team learn a lot about KDE and Qt programming during the course of dealing with bug reports, and many move on to developing the software itself. If you are just starting to learn programming, bug triaging is a great way to gain familiarity with the components and give practical support to the KDE community.
To join the Bugsquad, become a member of our project on Phabricator. We organize Bug Days, where we focus on a specific product, with the goal of reviewing all open bugs by the end of the day. These meetings occur primarily on #kde-bugs.
We have a Bugsquad calendar you can view or export as ICS to your calendar of choice. The calendar lists all of the upcoming Bug Days and what product we will be focusing on. These days are great times to get involved and ask questions!
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:
All regular Bugzilla users can perform standard editing functions. You can change a number of fields, including the product, component, version, platform, status, and more. You are restricted to only a few abilities, such as bulk editing, changing the Priority and Severity fields (Importance), or re-opening CLOSED bugs. After getting comfortable with the KDE Bugzilla process, you can request "contributor" privileges from Sysadmin, which will allow you to perform those actions.
Now that you have a list of bug reports, pick one and start working! Here is the optimal bug triaging workflow:
|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.|
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.
Not all real bugs affecting KDE software are actually caused by a fault in KDE software. The issue may be "upstream" or "downstream" of KDE.
"Upstream" means that the problem lies in an underlying technology that KDE software uses (e.g. Qt, X11, the Linux kernel). Others who make use of KDE software (e.g Linux distributions, 3rd party Plasma plugins) are downstream of KDE.
Examples of Upstream issues:
Examples of Downstream issues:
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.
|After asking for further information, mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" (or resolution "BACKTRACE" if you are waiting for a complete backtrace).|
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.
|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.|
|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. Write down any newly discovered steps to reproduce.
Write down the steps you performed. Ask the reporter if your steps missed something, or if anyone notices any other strange or non-default situation or configuration which may be related. Also ask the reporter for more information and mark it NEEDSINFO/WAITINGFORINFO.
Hopefully, you will get feedback from the reporters and you could gather more information to try to reproduce the bug or close the report as RESOLVED/WORKSFORME (or FIXED) after a short wait.
If you had to combine several steps to make your own "recipe" to reproduce, write them down. This kind of information is useful for the developers. If you had to use custom input data (text, or a file), you may want to attach it to the bug report. Don't forget to mention the environment and circumstances under which you can reproduce the bug.
Often a bug report isn't properly categorized, or lacks some information in the Bugzilla fields (which are useful for sorting and filtering). If a field isn't mentioned below, you don't need to change it. All users have permission to change most Bugzilla fields.
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.
As with the Product field, many bug reports are reported against the wrong component or none at all. Set the Component if you are able to determine a more appropriate one than the bug's current assignment.
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 from the list, please contact the software maintainer or the KDE Bugzilla admins to add the version.
This field is only important if the bug is related to one distribution or a specific system (the majority of bug reports are common to most platforms).
Mark the bug's severity. Some hints about the various severity options:
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:
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.
If you can reproduce the issue, and you are confident that you have set all fields correctly, set the bug report's status to CONFIRMED. This only applies to bugs; feature requests ("wishlist" items) don't need to be confirmed, since they're not bugs.
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:
You must close the bug report as RESOLVED/NOT A BUG with a humane explanation that bug reports can only contain a single issue. (Get Involved/Bug Reporting#One issue per bug report)
If the bug reporter or someone else included a patch, ask them to submit it using Phabricator, and remind them about Get Involved/Bug Reporting#Submit patches using Phabricator.2C not the bug tracker.
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.
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.