Bugreporting barrier is too low with the new Dr. Konqi

[Darío Andrés]

On Mon, Nov 2, 2009 at 1:47 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> Hi,
>

Hi. I'm going to talk as developer of part of DrKonqi (UI) and as a bug triager.

> it seems like the bugreporting barrier is too low now that Dr. Konqi has a
> "report this bug" button. In particular users are not presented with a list
> of possible duplicate reports according to the backtrace information and
> reproduction steps they supplied.
>

DrKonqi in KDE4.3 use the *same workflow* as the bugzilla wizard report:
- Login
- Enter keywords
- Listing duplicates (this duplicates are found using both the
keywords and the first three valid functions of the backtrace)
- User can suggest a duplicate
- Entering details + title of the report
- Submit

And this bugzilla report is only allowed if the backtrace is good
enough and the user is able to describe the problem (or to provide
some text about the situation)....

DrKonqi in KDE4.4:
- The keywords steps was removed (as it was useless)
- The duplicates page only searches using the backtrace functions (no keywords)
- The user can suggest multiple duplicates, or if he is sure about a
duplicate choice, he/she can attach the new information to that
existing report (and therefore not creating a new report) <- This last
thing could help a bit to fix the issue. It was difficult to implement
as adding a new comment (with a new backtrace) to an existing report
could cause **mess** (ex. adding a different backtrace affects
backtrace searching)
- The dialog that shows the possible duplicate information now uses
less jargon (ex. "RESOLVED/DUPLICATE" -> "The report is closed because
it is marked as duplicate of another report", and so on)
- The backtrace control was modified to be strict. We don't allow
not-perfect backtraces without description anymore (this is
considering that DrKonqi can already detect and install the debug
information packages for a crash...)

Some of this improvements are major changes which can't be backported.

> This is a major headache for us as we got basically 10 reports about the
> same thing in the last 5 days. Its tedious that we have to close those
> reports as duplicates ourselves, especially as the report already says its
> probably a duplicate of some other bug.
>

As I mentioned, now the users can attach new information to an
existing report without creating a new one.

Different options to solve this issue have been mentioned all over the
place as drkonqi wishes:

- When an user selects a possible duplicate:
  a) if that possible duplicate is marked as FIXED then show that the
report/issue is **FIXED** (big letters sign)
  b) if that possible duplicate is marked as DUPLICATE, and the
"parent" report is set to FIXED: - let the user check the parent
report and/or show the reporter that the issue/report is already
**FIXED**. (big letters sign)

** In any case, "backtrace matching" isn't always effecting and
DrKonqi uses simple heuristics, and relies into bugzilla searching
capabilities. We can't really ensure that the possible duplicate
reports listed are real duplicates. User (and/or triagers) need to
manually check them and compare the situations.

- Make the duplicate search step a required one (currently it is
stated that duplicate search is "optional", as some users can't
interpret/read backtraces or identify the situations). And if the
reporter can't find any possible duplicate, he/she needs to explicitly
state so <- not sure about this.

- For frequent crashes of the same application, an user suggested to
keep a local database of reported crashes. So if the backtrace of a
crash is found in this DB we disable the reporting process as "it was
already reported by the user itself"

- Implement a stricter/smarter backtrace matching logic to try to show
only real duplicates and encourage the users to properly check them
all. And/or do not show possible duplicates which are marked as
duplicate already to reduce the mess and the total ammount of the
reports the user needs to check/read.

- Let Dario_Andres clean the mess... (well, you can't rely on me forever...)

May be I forgot some other suggestion...

If you have any other idea in order to improve the process and reduce
our work, please tell us :)

References:
https://bugs.kde.org/show_bug.cgi?id=210044
https://bugs.kde.org/show_bug.cgi?id=209278
https://bugs.kde.org/show_bug.cgi?id=208243

> What can we do about this? I guess disabling Dr. Konqi is not an option, so
> is someone working on getting something similar to the wizard you have to
> go through when reporting at bugs.kde.org into Dr. Konqi?
>

You can disable DrKonqi automatic reporting process for your
application if you like, just call the KAboutData->setBugAddress("");.
I don't recomend such a thing as users won't know where to report
normal bugs, and I don't think it is a good idea at all.....

Regards

Darío Andrés
(Dario Andres @ bugs.kde.org; Dario_Andres @ #kde-bugs)

> Andreas
>
> --
> Your object is to save the world, while still leading a pleasant life.
>