bugzilla situation

[Martin Gräßlin]

On Friday 24 February 2012 19:11:12 Sven Burmeister wrote:
> Am Freitag, 24. Februar 2012, 08:06:41 schrieb Martin Gräßlin:
> > > 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.
> Maybe it's different for kwin but what I see is:
> 
> User asking on distro/KDE mailinglist/forum/IRC because xyz does not work.
> 
> 1. he gets an answer
> 1.1 known bug
> 1.2 me too -> the user might open a bug report
> 1.3 it works like this…
> 
> 2. he does not get an answer
> 2.1) frustrated and no bug report
> 2.2) frustrated and bug report
which sounds exactly like first level support which needs to become better so 
that point 2 never happens and point 1.2 is not handled by the user. Think 
about how awesome it is to get the feedback that the task has been delegated 
to the developers for further investigation :-)
> 
> > 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)
> 
> Well, most other apps do not depend on a special hardware driver, so while
> this might be true for kwin it's not for many other apps.
remove the hardware specific thing and I'm quite sure that it holds for almost 
all applications.
> 
> > 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
> 
> Dr.Konqui is mainly about crashes, I'd guess that most bugs in bko are not
> crashes. And they do ask "does sombody else get a crash when…".
For 2011 in KWin: 452 reported crashes, compared to 824 reported bugs from 
which only 213 were no "spam". 42 crashers were not marked as duplicates.

So for kwin more than the half of all reports are crashers. Well in 2011 there 
was the mentioned kwin-intel problem on Ubuntu.
> 
> > > 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).
> 
> What you miss is that most of your users do not even have a bko account.
> Hence most of your users never report a bug but give-up before that.
yes it's true. I consider that at least 100 users have the same problem per 
reported bug.
> Yet
> it's true that the longer it takes until they get the first answer the
> lower the chance to get some feedback because they have already worked
> around the issue or given-up.
in kwin we are normaly able to answer in hours :-)
> 
> > > 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.
> 
> Most of that could easily be handled by a script the user runs and whose
> output he attaches to the bug report.
scripts would be awesome if there would not be the problem of distributions. 
But what about mesa-utils not being installed by default (so no glxinfo) and 
things you have to extract from the debug output of KWin?
> I would guess you could have saved a
> lot of time and you would have enabled people on the forums to point users
> to that script before reporting bugs.
> 
> > But to get there the bugtracker has to be closed and *cleaned*. Drop all
> > bugs - nothing useful in it anyway.
> 
> That claim is rubbish because it would mean that nobody can report any
> useful bug report for any app in bko. Which is obviously wrong. It would
> also mean that either KDE devs do not report bugs or are themselves not
> capable of creating useful bug reports.
given that we have for KWin > 350 open reports and as I mentioned I need an 
hour to clean this amount for another 10 reports. So this are 35 hours just to 
clean it. Yes it's faster to just reinter the valid bugs. It's a pity I know, 
but we just waited too long to get to that mess.

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/c8b30620/attachment.sig>