bugzilla situation

[Martin Gräßlin]

On Friday 24 February 2012 02:15:54 Sven Burmeister wrote:
> Am Mittwoch, 22. Februar 2012, 19:00:26 schrieb Martin Gräßlin:
> > Personally I'm not sure whether the MeeGo bugzilla can be compared to
> > the KDE one (technical oriented vs. user oriented). From my personal
> > experience (KWin bugtracker is felt > 90 % a user support forum)
> 
> My claim is that most of that "user support" only ends-up in bugzilla
> because people did not get help somewhere else, e.g. because only
> developers are familiar enough with the code to understand the issue.
No, that is clearly not the case and it's not the case that the users are 
searching for user support. It is they have a problem and consider it a bug. 
They don't know, that:
* they just didn't find that damn config option
* they have installed the wrong driver/distro/whatever
* how to circumvent that stupid driver crash
* many many more things which turn out to be user support (interesting side 
node: the second most often reported bug against KWin is Compiz crashing. That 
says all about the usefulnes of reports)

and that's what first level support is actually for: filtering the noise so 
that only the real bugs get through.

Just consider the bug named "kwin-intel" - each of the duplicates is about 2 
min work. Each of the duplicates is set by a developer. Each of the duplicates 
is simple user support. Nothing the developers can do about, but users support 
was possible (use a workaround or switch to a distribution not shipping broken 
drivers and failing to fix it in the complete cycle given that the patches 
exist).
> 
> Most users do not like reporting bugs and thus ask somewhere else first –
> and only after that, if at all, they report an issue.
this is clearly not the case with DrKonqui. They just report
> The majority of users
> only complains about the buggy piece of software without reporting any
> issues. So only if they get no answer on IRC, a forum a mailinglist etc.
> they leave their issue with the developer at bugzilla to document it and
> wait for an answer.
no, I would even deny that they wait for an answer. Please do a search for 
WAITINGFORANSWER on the KWin product (I need to add that to my statistics).
> 
> Leaving the user without answer will not increase KDE's reputation. Thus the
> discussion should not be about how to restrict user access to bugzilla but
> rather how to help them before they feel the need to report at bugzilla.
> Filling out those forms is nothing users like to do.
agreed. The proper way has to be to not let users enter support questions into 
the bugzilla. My perfect scenario is:
a) first level support to help users
b) if first level support cannot help it goes to second level support
c) second level support identifies the important information from first level 
support, verifies that there is no bug reported yet and reports bug
d) developers can concentrate on fixing that bug

in case of KWin that would mean that we get all relevant informations without 
asking for it:
* distribution
* version (in case not default of distribution, how installed)
* which compositing backend is use
* which effects are used
* which effects are active when the problem occurs
* hardware
* driver/version for that hardware
* glxinfo -l output

Consider that we have to ask again and again for all those things to find out 
in the end that it is a known issue with $foo driver in combination with $bar 
feature. All these things could so easily be handled by a first level support.

But to get there the bugtracker has to be closed and *cleaned*. Drop all bugs 
- nothing useful in it anyway.
> 
> > I would
> > not allow users to edit/close all bugs. We have too many users who
> > report bugs, get it set to WONTFIX/INVALID and just reopen it. If I now
> > imagine that everyone would be allowed to do so...
> 
> If one wants users to keep reports up-to-date one should e.g. allow them to
> edit any bug report's version fields.
yes that might make sense to allow them to change the version field. But in 
the scenario outlined above it would not be needed as the second level support 
already entered it correctly.

Cheers
Martin
-------------- 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/20120224/4887e396/attachment.sig>