On Fri, Feb 24, 2012 at 8:06 PM, Martin Gräßlin <mgraess...@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
