= Triaging Krita Bugs =
There are over 1000 bugs and 350 wishes reported against Krita per year, and that number is rising. The Krita developers cannot handle that stream on their own! Please consider helping out by triaging bugs. This document gives some simple guidelines to get started, and some common cases that can often be answered with a standard text.
For more details, see also https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging
== Bugs, Wishes and Support Requests ==
* A bug is a problem in Krita's code: a crash, or something that definitely doesn't work as it should.
* A wish is a query about missing functionality
* A support request is about something the user doesn't understand and can often be answered with a link to the faq.
== Status flow ==
A bug begins as UNCONFIRMED. When triaging, only UNCONFIRMED bugs are still relevant.
=== Platform ===
If the user has not entered the Platform correctly (i.e., it is "unspecified/Linux"), then ask which platform they are using. Mark the bug as NEEDDINFO/WAITINFORINFO. Text to paste:
"Please indicate your operating system correctly. For Linux, select the distribution, appimage or compiled from sources and Linux, for Windows, select MS Windows/MS Windows, for OSX or macOS, select macports, disk images or homebrew and OSX."
If the user has selected Windows CE for platform, set it to MS Windows without asking them.
=== Version ===
If the user has not entered the version (i.e., the version is unspecified), ask them for the version and mark the bug as NEEDDINFO/WAITINFORINFO. Text to paste:
"Please select the version of Krita you are using. You can find the version in Help/About Krita."
=== Can Reproduce ===
* If you can reproduce the bug, add a comment indicating you can reproduce it, maybe with clearer steps to reproduce and anything pertinent that you observed. If you have a backtrace, also add it. Set the bug status to CONFIRMED and add the 'triaged' keyword to the keywords.
* If you can reproduce the bug, and want to go the extra mile, use an older version of Krita to see whether you could reproduce it there as well. If you couldn't, it's a _regression_, so add the regression keyword to the keywords and mark which version of Krita the latest was that did not have the bug.
=== Cannot Reproduce ===
* If you cannot reproduce, the user either has not given enough information or the bug is specific to their system.
** If there is not enough information, ask for more information. Depending on the report, the steps to reproduce might need to be described more clearly and/or a screenshot, a screen recording or the original files might be necessary. Set text (ask for what you think is needed):
"I am sorry, I cannot reproduce your issue. Could you specify the steps to reproduce more clearly, and maybe add a screen recording/screenshot/original file"
Mark the bug as NEEDINFO/WAITINGFORINFO.
** If the issue seems to be specific to the user's system, ask for the output of help/System information for bug reports as well. Set text:
"I am sorry, but I cannot reproduce the bug on my system. Please add the output of help/System Information for Bug reports as well."
Mark the bug as NEEDINFO/WAITINGFORINFO.
== Importance ==
Importance is a tool for developers, not for bug reports. It's developers and triagers who decide what the importance is. If a bug reporter complains about a change in importance, use this text:
"I am sorry, but the importance field is a tool for the developers to work with. Please do not change the importance back."
There are the following Importances:
* Critical: the bug leads to immediate dataloss. Example: a saved file cannot be opened in Krita
* Grave: shouldn't be used, it doesn't mean a thing
* Major: it's a bug, but it's kinda important.
* Crash: the bug is about a crash or an assert (1)
* Normal: it's a bug
* Minor: it's a bug, but it's kinda unimportant
* Wish: it's a feature request
* Task: not used.
The main difference is between Wish and the rest: Wishes are feature requests, and don't need immediate triaging. A wish bug is a bug that asks whether some functionality can be added to Krita, or complains that some functionality is missing.
The rest are bugs, that is, problems in Krita that can be fixed by changing Krita's code.
However, we also get many reports that are not bugs and not wishes: reports that are basically users asking for help because they do not understand Krita or their computer, or what a file is, or that Krita isn't the same application as Photoshop. Those reports need to be weeded out, and the status set to INVALID.
=== Guidance for using Importance ===
* If you encounter a bug that reports dataloss when loading a saved file, set it to critical.
* If you encounter a bug that reports a crash or an assert but is not set to crash, set it to crash.
* If you encounter a report that asks for functionality that is not currently present, set it to wish.
* If you encounter a report that is a user request, check whether you can reply with a link to the faq (https://docs.krita.org/KritaFAQ), and maybe a canned answer, and change the status of the bug to INVALID.
=== Footnotes: ===
1) Crash or assert. These are different things. A crash happens when Krita spontaneously stops working _or_ hangs. An assert happens when Krita stops working because we, developers, have added some code to detect an invalid state.
Asserts are printed to the terminal or shown in a popup window. You can identify an assert by asking for terminal output, debugview output or by checking the backtrace, if there is one.
if the backtrace contains a line like
'''> SAFE ASSERT (krita): "!sanityCheckPointer.isValid()" in file /tmp/nix-build-krita-4.0.0-pre2c.drv-0/krita-1b1695a/libs/ui/KisDocument.cpp, line 490'''
Or another mention of assert, Q_ASSERT or similar, it's an assert/
== Canned Answers and Recognizing ==
XXX