Bugreporting barrier is too low with the new Dr. Konqi

[Matt Rogers]

On Tuesday 03 November 2009 04:25:27 Myriam Schweingruber wrote:
> Hi all,
> 
> On Tue, Nov 3, 2009 at 10:46, Mark Kretschmann <kretschmann at kde.org> wrote:
> > On Mon, Nov 2, 2009 at 5:47 PM, Andreas Pakulat <apaku at gmx.de> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091103/39bdc3fa/attachment.sig>