DrKonqi improvement idea

[Christoph Feck]

On Tuesday 13 March 2012 10:30:59 Thomas Zander wrote:
> Quoting Ben Cooksley <bcooksley at kde.org>:
> > Whilst I have not evaluated it's compatibility with Bugzilla 4.2,
> > I do not suppose anyone has looked at
> > https://launchpad.net/bugzilla-traceparser ?
> 
> The traceparser might be a good-enough solution for finding
> duplicates and helping the reading of backtraces, yes.
> 
> This thread is a bit more about solving the inital problem in a
> different way since the actual usage of bugzilla for processing
> backtraces is something that we probably want to sidestep in the
> first place.  Here is why;
> 
> * users that get a crash have to have a bugzilla account already if
> they want to give it to us.
> This is a problem because developers don't get a good insight of
> how often things crash due to this higher level of contribution.
> Yes, reporting a backtrace makes the user a contributor!
> 
> * users that get a crash are asked to themselves figure out if the
> trace is a duplicate and are offered the option to add a cc instead
> of a new report.
> This is a problem because users are not capable of doing this and
> it feels less-then-helpful to just cc yourself on a bugreport,
> which means a lot of people just choose the safe route of creating
> a new report.

I have long been interested why users keep reporting duplicates. 
Instead of guessing, let's just ask them in a nice way. I added 
https://bugs.kde.org/show_bug.cgi?id=295919#c1 to a frequently 
reported bug, and maybe we can this way get some insights. Unless 
someone objects, this survey could be sent to reporters of frequently 
reported crashes (maybe not in the comment, but per reply).

My guess is that DrKonqi simply does not make it clear that the bug 
has already been reported several times.

> * bugzilla holds backtraces as plain text in comments. Often mixed
> with user-typed text.
> This is a problem because it makes parsing and generating
> statistics and automatic re-assignment near impossible.  Consider
> how many ark and konq bugs there are that are actually a crash
> inside of a random kpart...
> 
> * bugzilla is meant to be for developers, users find it provides an
> overkill of info and getting simple "disable feature X to stop the
> crashing" is just impossible to communicate with the user right
> now.
> 
> * reporting to bugzilla means we have exactly one place where
> *everything* kde based goes. A monolithic database shared by
> hudreds of projects with 15 years of history.
> This one is thinking ahead, thinking about the future handling of
> project tasks and bugs and attacking the general dissatisfaction
> with mozillas bugzilla tool (which I won't address here).
> This database usage is a problem because it means the data is
> unavailable for innovative (read; not yet invented) usage in
> project-specific task-handling. Its also a problem for groups or
> indivuduals that are geographically too far from bugs.kde.org to
> have nice response times.
> 
> Ideally the improvement idea that I see forming in this thread
> makes people stop reporting all backtraces to bugzilla but instead
> go to a component that solves all those issues and one that
> distills the inflow of traces into a limited number of issues. 
> Those limited number of issues can then be made into bugzilla
> tasks which are handled as normal.
> 
> So, I'm interested (and active) in solving this in a way that is
> only a little related to bugzilla and get free from the thinking
> imposed by bugzilla.

Bugzilla has a long tradition of being a tool that annoys users, 
developers, as well as bug triagers. Anything that improves the 
situation is welcomed :)

Christoph Feck (kdepepo)
KDE Quality Team