Bugreporting barrier is too low with the new Dr. Konqi

Hi,

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.

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.

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?

Andreas

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

[Albert Astals Cid-2]

A Dilluns, 2 de novembre de 2009, Andreas Pakulat va escriure:
> Hi,
>
> 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.

Last time i reported a but using the new Dr Konqi i think i got a list of
duplicate reports.

Albert

[Shaun Reich]

On Mon, Nov 2, 2009 at 7:40 PM, Albert Astals Cid <aacid@...> wrote:

> A Dilluns, 2 de novembre de 2009, Andreas Pakulat va escriure:
>> Hi,
>>
>> 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.
>
> Last time i reported a but using the new Dr Konqi i think i got a list of
> duplicate reports.
>
> Albert
>

Likewise. Although I think it was easily skippable, last time I had to use it.
The duplicate checker actually is pretty nice, along with other
aspects, and in my opinion better than BKO. But that's coming from a
person who hates BKO.

--
KDE Developer,
Shaun Reich

On Mon, Nov 2, 2009 at 1:47 PM, Andreas Pakulat <apaku@...> 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.
>

On 02.11.09 19:01:07, Darío Andrés wrote:
> On Mon, Nov 2, 2009 at 1:47 PM, Andreas Pakulat <apaku@...> wrote:
> [...]
> 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 :)

Thanks for the extensive information, indeed the KDE4.4 dialog sounds
like a major improvement already. The only suggestion I have from my
experience with KDevelop is that one could disable submitting a report
via Dr. Konqi to bugzilla if there's a duplicate found. However I do see
your point there that the user alone might not identify the situation
correctly.

Ok, I guess I'll just try to live with what we get right now and hope
that distributions will ship the new KDevelop beta really soon so the
reports I've closed recently stop..

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

I totally agree on this.

Andreas

--
You have an unusual understanding of the problems of human relationships.

[John Tapsell-3]

2009/11/2 Andreas Pakulat <apaku@...>:
> Hi,
>
> 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.

I was about to send a similar email.  I am now getting several emails
every single day for the same crash, for a bug that I fixed in svn
awhile ago.

  Very soon I will have to ignore bugzilla altogether :-/

John

On Mon, Nov 2, 2009 at 5:47 PM, Andreas Pakulat <apaku@...> wrote:

> 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.
>
> 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.
>
> 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?

I have to agree with Andreas here. But I'd like to elaborate some
more: For one, some of the newer improvements in Dr Konqi are really
good, e.g. the detection of backtrace validity. I think that there has
been made some excellent progress with it.

However, the number of duplicate reports has skyrocketed for us
(Amarok), and this is giving us major headaches. Any measures to
reduce the number of dupes would be appreciated, as we spend far too
much time with triaging them.

--
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org

Hi all,

On Tue, Nov 3, 2009 at 10:46, Mark Kretschmann <kretschmann@...> wrote:
> On Mon, Nov 2, 2009 at 5:47 PM, Andreas Pakulat <apaku@...> wrote:
>> 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.
...
> I have to agree with Andreas here. But I'd like to elaborate some
> more: For one, some of the newer improvements in Dr Konqi are really
> good, e.g. the detection of backtrace validity. I think that there has
> been made some excellent progress with it.
>
> However, the number of duplicate reports has skyrocketed for us
> (Amarok), and this is giving us major headaches. Any measures to
> reduce the number of dupes would be appreciated, as we spend far too
> much time with triaging them.

I don't think that Dr. Konqi is to blame here, it's more the user:
they don't read, they have a nasty behavior of clicking on next
without ever reading what is on the screen, and considering that they
have not a clue what is written there (and don't understand a
backtrace anyway, even less would be able to see where a duplicate
report is a duplicate or know what a crash handler is), so why are you
all trying to put the blame on a tool that is really doing a great
work?

We have inherited users from the Windows world where they are taught
to click instead of thinking by themselves, and probably did exactly
the same when they had bugs in Windows. "Click next" is all that they
can see. If we want to get rid of duplicate messages, we either
educate our users or prevent them from reporting bugs, as easy as
that. Of course we can add flashing lights and big letters asking them
to *THINK*, but I doubt it will improve that fast.

The new duplicates are mostly coming in when there is a new release in
a major distro, as it is the case for Kubuntu right now. It is aimed
at end users, not geeks or nerds or developers, so don't expect
miracles.

What we should improve is having more bug triagers, and every major
project should have its own triagers that know the application and do
this on a daily basis. Of course it causes work, what do you expect?
The more users we have in KDE, the more we will get such dupes, that
is inherent to the fact that people don't use trunk. The bigger the
userbase, the more work it will be for us, there is nothing strange in
that, I think we should get prepared for that rather than blaming
tools that are doing their job very well.

If there is something to blame I would rather look on the bugzilla
side, it is maybe not the appropriate tool for bug handling at that
scale, and this will get worse the more users we get. I know there is
not much of alternatives in the Free Software world, but there are
other tools around that are free to use for Free Software projects,
scaling much better than bugzilla ever will. Some lobbying there might
convince the manufacturers of these tools to free their code, who
knows? Just MHO.


Regards, Myriam
--
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Mark and John: have you read my reply email ? In that mail, I describe
the current situation in KDE4.4 and I also propose several ways to
improve the current situation... may be you can look at them or
propose new ones... I *need* feedback on this.
According to our BKO statistics, non-crash reports also increased...
so, this problem is also caused by the increasing amount of KDE4 users
(just a guess)

Regards
Darío Andrés (DrKonqi dev, bugs.kde.org triager)

[John Tapsell-3]

2009/11/2 Darío Andrés <andresbajotierra@...>:
> - 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.

Go for this, including the "explicitly state so".

If there are any bugs with a duplicate back trace then either:

1) The user cannot tell if it's a duplicate or not.  In this case, I'd
rather just assume it _is_ a duplicate, and ignore.

2) If the user _can_ tell it's not a duplicate, despite the similiar
backtrace (which in itself is unlikely imho), then make so that they
really have to state that it's not a duplicate.


In the case of a duplicate bug report, it would be nice to immediately
tell the user

1) Whether it is already fixed.
2) Which release of KDE will have the fix
3) Possible workarounds

I'm not sure which of these are actually possible with bugzilla.

John

On Tue, Nov 3, 2009 at 1:17 PM, John Tapsell <johnflux@...> wrote:
> I'm not sure which of these are actually possible with bugzilla.

Which brings us to the next point: Bugzilla is just not very good, to
say the least. Some of us would love to migrate to a different system,
and in fact we have tentatively started evaluating other options.

Nokia is now using the JIRA [1] bug tracking system for Qt. I'm
personally very interested in that, as I know first hand that
Atlassian makes excellent software. However, JIRA is only
free-as-in-beer, and I can see how that would make certain people go
mental.

Another option could be the Redmine [2] system, which we're also
taking a closer look at. Redmine is entirely Free Software, so it's
only a matter of judging its technical adequacy.


[1] http://en.wikipedia.org/wiki/JIRA_(software)
[2] http://en.wikipedia.org/wiki/Redmine

--
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org

On Tue, Nov 3, 2009 at 9:17 AM, John Tapsell <johnflux@...> wrote:
> 2009/11/2 Darío Andrés <andresbajotierra@...>:
>> - 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.
>
> Go for this, including the "explicitly state so".
>

Mh, ok, this could be implemented...

> If there are any bugs with a duplicate back trace then either:
>
> 1) The user cannot tell if it's a duplicate or not.  In this case, I'd
> rather just assume it _is_ a duplicate, and ignore.
>
> 2) If the user _can_ tell it's not a duplicate, despite the similiar
> backtrace (which in itself is unlikely imho), then make so that they
> really have to state that it's not a duplicate.
>

The problem I see here is that the backtrace matching logic is not
always reliable. You could be comparing an incomplete backtrace with a
complete backtrace. (some functions missing), and even in that case
the incomplete backtrace could be useful (the missing functions are
not needed to determine the crash cause)

>
> In the case of a duplicate bug report, it would be nice to immediately
> tell the user
>
> 1) Whether it is already fixed.

Yes, I could try to achieve this (if it is duplicate, load the parent
report information and check for its status)
It would be easier if bugzilla had an option to only list "main"
reports (list reports which are not duplicate of another one); so only
the real reports will be listed and possible duplicate and the
reporter has to check less bug reports in order to determine if it
his/her bug is a duplicate or not.

> 2) Which release of KDE will have the fix

This is not really easy or reliable, the target milestone flag of
bugzilla is not really used everywhere, and even if it is used it
could not match the real situation. A complicated solution will be
parsing the comment that include the log of the SVN commit that closed
that bug report (considering that it was closed by a SVN commit, which
is not always true), getting the svn revision and comparing the
versions with the one in the SVN server....

> 3) Possible workarounds
>

If there are possible workarounds there should be listed in the
comments of that report already. But I guess there is no reliable way
of detect such workarounds without using some tag in the comment or
something....

> I'm not sure which of these are actually possible with bugzilla.
>
> John
>

Regards
Darío A.

On Tue, Nov 3, 2009 at 9:48 AM, Mark Kretschmann <kretschmann@...> wrote:

> On Tue, Nov 3, 2009 at 1:17 PM, John Tapsell <johnflux@...> wrote:
>> I'm not sure which of these are actually possible with bugzilla.
>
> Which brings us to the next point: Bugzilla is just not very good, to
> say the least. Some of us would love to migrate to a different system,
> and in fact we have tentatively started evaluating other options.
>
> Nokia is now using the JIRA [1] bug tracking system for Qt. I'm
> personally very interested in that, as I know first hand that
> Atlassian makes excellent software. However, JIRA is only
> free-as-in-beer, and I can see how that would make certain people go
> mental.
>
> Another option could be the Redmine [2] system, which we're also
> taking a closer look at. Redmine is entirely Free Software, so it's
> only a matter of judging its technical adequacy.
>
>
> [1] http://en.wikipedia.org/wiki/JIRA_(software)
> [2] http://en.wikipedia.org/wiki/Redmine
>

This is a bit out of my scope, but if we are going to choose a new bug
tracking system, it could be useful to me and DrKonqi if that tracker
had a XMLRPC interface (or another easily implementable communication
system). We are currently relying on parsing bugzilla HTML (which is
indeed a nasty thing to do) because current bugzilla XMLRPC interface
is incomplete and it is experimental (it changes within releases).

Another thing about such a change is that you will need to maintain
the bugzilla version running until the last KDE version including a
bugzilla-enabled DrKonqi is obsoleted. (ex. if we migrate to another
bugtracking system and I include the integration with it in KDE4.6;
you won't be able to remove bugzilla until KDE4.6 becomes the stable
branch, and KDE4.5 and KDE4.4 become "deprecated")

> --
> Mark Kretschmann
> Amarok Developer
> www.kde.org - amarok.kde.org
>

Regards
Darío A.

[Ian Monroe-6]

2009/11/2 Darío Andrés <andresbajotierra@...>:

> On Mon, Nov 2, 2009 at 1:47 PM, Andreas Pakulat <apaku@...> 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:

I still question whether it makes sense to have the bugs sent to
bugzilla, given the time it takes to handle them. The point of Dr.
Konqui is to lower the entry to bug reporting. This creates a problem:
it lowers the entry to bug reporting.

For Amarok 1.4 we sent backtraces to a mailing list. It was handy, I
would just search the mailing list for a class to see if it had any
related crashes. I'm not sure thats the best solution, but it does
seem like a mistake to mix bugs that come from such an semi-automated
process (eg the user didn't have to sit down and decide to open up
bugs.kde.org) and normal bugs.

Bugzilla itself is also a problem, since you can't edit the bug
description so its impossible to do any real bug management. But thats
another issue. :D

Ian

[David Jarvie-4]

On Tue, November 3, 2009 10:25 am, Myriam Schweingruber wrote:

>> However, the number of duplicate reports has skyrocketed for us
>> (Amarok), and this is giving us major headaches. Any measures to
>> reduce the number of dupes would be appreciated, as we spend far too
>> much time with triaging them.
>
> I don't think that Dr. Konqi is to blame here, it's more the user:
> they don't read, they have a nasty behavior of clicking on next
> without ever reading what is on the screen, and considering that they
> have not a clue what is written there (and don't understand a
> backtrace anyway, even less would be able to see where a duplicate
> report is a duplicate or know what a crash handler is), so why are you
> all trying to put the blame on a tool that is really doing a great
> work?

Of course, the solution to this problem which nobody seems to have
noticed, is simply to produce bug-free software. Then if users are so
misguided as to submit any bug reports, we can happily ignore them. ;)

--
David Jarvie.
KDE no-bugs developer.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

On Tuesday 03 November 2009, Darío Andrés wrote:
> This is not really easy or reliable, the target milestone flag of
> bugzilla is not really used everywhere, and even if it is used it
> could not match the real situation. A complicated solution will be
> parsing the comment that include the log of the SVN commit that
closed
> that bug report (considering that it was closed by a SVN commit,
which
> is not always true), getting the svn revision and comparing the
> versions with the one in the SVN server....
 
Maybe a simpler solution would be to standardize on a tag like
FIXEDIN: 4.3.3
(which we would use under the BUG: tag in the commit log).

This could even then set the target milestone flag in bugzilla.

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror
(http://www.konqueror.org).

On Tue, Nov 3, 2009 at 13:17, John Tapsell <johnflux@...> wrote:
> In the case of a duplicate bug report, it would be nice to immediately
> tell the user
>
> 1) Whether it is already fixed.
> 2) Which release of KDE will have the fix
> 3) Possible workarounds
>
> I'm not sure which of these are actually possible with bugzilla.

Good points.

I think the easiest way to implement this is to create a layer between
DrKonqi and bugzilla. A database where all backtraces are sent to, good
duplication searching can get implemented, additional information (needed
for those points) can get added - and for real bugs a bugzilla entry
can be created.

This would require manual backtrace triaging too - but can be done in
a specialized,
optimized (web-?) application.

Think of it like the brainstorm forum.

Niko

On Tuesday 03 November 2009 10:11:11 Ian Monroe wrote:

> 2009/11/2 Darío Andrés <andresbajotierra@...>:
> > On Mon, Nov 2, 2009 at 1:47 PM, Andreas Pakulat <apaku@...> 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:
>
> I still question whether it makes sense to have the bugs sent to
> bugzilla, given the time it takes to handle them. The point of Dr.
> Konqui is to lower the entry to bug reporting. This creates a problem:
> it lowers the entry to bug reporting.
>
> For Amarok 1.4 we sent backtraces to a mailing list. It was handy, I
> would just search the mailing list for a class to see if it had any
> related crashes. I'm not sure thats the best solution, but it does
> seem like a mistake to mix bugs that come from such an semi-automated
> process (eg the user didn't have to sit down and decide to open up
> bugs.kde.org) and normal bugs.
>
> Bugzilla itself is also a problem, since you can't edit the bug
> description so its impossible to do any real bug management. But thats
> another issue. :D
>

Potentially fixed by the layout change I've made. See
http://bugstest.kde.org/show_bug.cgi?id=129829 for an example.

If people are ok with this, then I'll complete the change and push it to the
live site.

> Ian
>

--
Matt

On Monday 02 November 2009 15:34:20 Shaun Reich wrote:

> On Mon, Nov 2, 2009 at 7:40 PM, Albert Astals Cid <aacid@...> wrote:
> > A Dilluns, 2 de novembre de 2009, Andreas Pakulat va escriure:
> >> Hi,
> >>
> >> 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.
> >
> > Last time i reported a but using the new Dr Konqi i think i got a list of
> > duplicate reports.
> >
> > Albert
>
> Likewise. Although I think it was easily skippable, last time I had to use
>  it. The duplicate checker actually is pretty nice, along with other
> aspects, and in my opinion better than BKO. But that's coming from a
> person who hates BKO.
>

Knowing what you hate about BKO (private mail is fine for this) would help.
This will let me actually work on fixing it. :)
--
Matt

On Tuesday 03 November 2009 04:25:27 Myriam Schweingruber wrote:

> Hi all,
>
> On Tue, Nov 3, 2009 at 10:46, Mark Kretschmann <kretschmann@...> wrote:
> > On Mon, Nov 2, 2009 at 5:47 PM, Andreas Pakulat <apaku@...> wrote:
> >> 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.
>
> ...
>
> > I have to agree with Andreas here. But I'd like to elaborate some
> > more: For one, some of the newer improvements in Dr Konqi are really
> > good, e.g. the detection of backtrace validity. I think that there has
> > been made some excellent progress with it.
> >
> > However, the number of duplicate reports has skyrocketed for us
> > (Amarok), and this is giving us major headaches. Any measures to
> > reduce the number of dupes would be appreciated, as we spend far too
> > much time with triaging them.
>
> I don't think that Dr. Konqi is to blame here, it's more the user:
> they don't read, they have a nasty behavior of clicking on next
> without ever reading what is on the screen, and considering that they
> have not a clue what is written there (and don't understand a
> backtrace anyway, even less would be able to see where a duplicate
> report is a duplicate or know what a crash handler is), so why are you
> all trying to put the blame on a tool that is really doing a great
> work?
>
> We have inherited users from the Windows world where they are taught
> to click instead of thinking by themselves, and probably did exactly
> the same when they had bugs in Windows. "Click next" is all that they
> can see. If we want to get rid of duplicate messages, we either
> educate our users or prevent them from reporting bugs, as easy as
> that. Of course we can add flashing lights and big letters asking them
> to *THINK*, but I doubt it will improve that fast.
>
> The new duplicates are mostly coming in when there is a new release in
> a major distro, as it is the case for Kubuntu right now. It is aimed
> at end users, not geeks or nerds or developers, so don't expect
> miracles.
>
> What we should improve is having more bug triagers, and every major
> project should have its own triagers that know the application and do
> this on a daily basis. Of course it causes work, what do you expect?
> The more users we have in KDE, the more we will get such dupes, that
> is inherent to the fact that people don't use trunk. The bigger the
> userbase, the more work it will be for us, there is nothing strange in
> that, I think we should get prepared for that rather than blaming
> tools that are doing their job very well.
>
> If there is something to blame I would rather look on the bugzilla
> side, it is maybe not the appropriate tool for bug handling at that
> scale, and this will get worse the more users we get. I know there is
> not much of alternatives in the Free Software world, but there are
> other tools around that are free to use for Free Software projects,
> scaling much better than bugzilla ever will. Some lobbying there might
> convince the manufacturers of these tools to free their code, who
> knows? Just MHO.
>
>

My personal opinion is that the issue revolves more around how we're using
bugzilla vs. bugzilla itself. If it really sucked that badly, it wouldn't be
the de facto standard for nearly ever large open source project.

If there are concrete improvements that you would like made, please suggest
them by filing a wishlist against b.k.o itself (it has its own product in
bugzilla) so that I at least know what you want. Others have done this, and
while I tend to be rather slow sometimes, I do care about getting any
improvements made that are beneficial to others.
--
Matt