bugzilla situation

[Ben Cooksley]

On Fri, Feb 24, 2012 at 8:06 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> 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)

Is there a page somewhere (such as on Userbase) which documents these
broken driver/distribution combinations - and the hardware generally
associated with it?

In regards to the Compiz component, is that something KDE ships - or
is that something Compiz ships? If it is something Compiz ships, it
should probably be blocked....

> 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

Only if it is a crash. Last I heard DrKonqi included functionality to
only add the backtrace to the existing report - does this not work
with KWin?

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

Some users do await replies. Unfortunately there is a not so small
segment which never read replies.

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

Note that in many cases, "first level support" as it were already
exists - however we ask the user themselves to report the bug if we
believe it to be a valid bug.

Unfortunately, without a page as mentioned above with known issues /
broken combinations which we can point the users to we have no other
choice other than to believe it is an actual bug - which should be
reported.

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

These should be reported anyway by DrKonqi if it is not - as many
other applications need them as well to determine if a report is
useful / a duplicate / known issue.

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

I'm not aware of any documented list of these broken combinations, at
least at the moment.

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

Regards,
Ben