bugzilla situation

[Sven Burmeister]

Am Freitag, 24. Februar 2012, 18:51:11 schrieb Martin Gräßlin:
> On Friday 24 February 2012 19:32:10 Andras Mantia wrote:
> > On Friday, February 24, 2012 06:10:23 PM Thomas Lübking wrote:
> > > Am 24.02.2012, 09:44 Uhr, schrieb Andras Mantia <amantia at kde.org>:
> > > > Bugzilla is not a to-do list, it is for what else... a bug (and
> > > > wishlist)
> > > > reporting tool for users.
> > > 
> > > The problem here that this is noise prone and the low entropy isn't
> > > helping anyone (and i'm not talking about users should not state their
> > > opinion or whatever)
> > 
> > The point is you can't avoid noise. How would you do that?
> > Remove Dr. Konqui? Close bugzilla to the public and allow only for some to
> > report? Moderate it?
> > 
> >  If you can moderate it, it means you have time and resource to do it, so
> > 
> > you could have done until now as well. The rest is not a real solution
> > (maybe Dr. Konqui is, but then you will also lose valid reports).
> > Any other suggestion?
> 
> -> first level support
> 
> issues are not opened on the bug tracker but in a user support management
> system - e.g. forums.kde.org. Only if the supporters figure out that there
> is a real bug, they will open a bug report. This is high filtered, all the
> information present.
> 
> Just to give you a feeling about what we are talking in KWin:
> reported bugs in 2011: 824
> bugs not marked as "spam" in 2011: 213
> bugs fixed in 2011: 197
> 
> to filter out ten "spam" reports I need an hour. To fix a  simple issue I
> need with reviewboard etc. etc. maybe max half an hour. To search the
> bugtracker to find a fixable bug I need as long as filtering the spam, that
> is after reading about an hour of spam I find a fixable bug.
> 
> So consider I have an hour I want to spend for bug fixing - it is gone
> before I find a fixable bug. It annoys me and I mostly stopped using the
> bug tracker to manage bugs. So why do I need it then?
> 
> > > Luckily this isn't a must.
> > > a) NO system message should be posted to bugs (adding CC etc. isn't but
> > > is
> > > available in bug activities, so why is duping or Dr. Konqi attaching a
> > > trace?)
> > > b) change the DEFAULT message order to "description" -> newest ->
> > > oldest,
> > > users (passing by) will not edit bugzilla presets (if ever they know
> > > about)
> > 
> > With this I agree, we could tweak the defaults.
> > 
> > > c) make the "description" (that is the original report message) editable
> > 
> > > by component owners ANYTIME - this here:
> > Bug editing/cleaning up makes sense (still doesn't solve the ORIGINAL
> > noise, but indeed, you can clean it up), and indeed Bugzilla doesn't help
> > with it (at least the current version), contrary to JIRA for example. But
> > you still have the problem that you need to spend time to do that.
> 
> which is fine if afterwards I have a bug report stating what it is about and
> I don't have to scroll through half an hour of user things to figure out
> again what it was about.
> 
> > > > If you wish to organize your tasks, I'm afraid you should do in
> > > > another
> > > > tool.
> > > 
> > > That doesn't cut it. *I* can organize my stuff in *my* *private* - but
> > > that information is entirely exclusive.
> > > It doesn't change anything for anybody else and esp. not for the user
> > > with
> > > a problem.
> > 
> > This was a suggestion for the project, not the individual. Bugzilla is not
> > a task organizer. For that we have other tools, use them. Those entries
> > might refer to bugzilla bugs.
> 
> have a look how Mozilla uses bugzilla (IIRC it is developed by Mozilla).
> There it is a task organizer.
> 
> > > > If you don't like users reporting bugs, close the product for
> > > > bugzilla,
> > > > ignore the users, and do what you want.
> > > 
> > > Nonsense. This is not about "I don't like hearing about bugs" but about
> > > "i
> > > don't like my bugs being spammed"
> > 
> > See above and my mail. IMO you can't avoid that with the userbase we have.
> > You have to live with it. Of course, I was ironic, and I hope nobody will
> > do that, but I know there are developers from teams who don't really care
> > about bugzilla reports. That's fine, I can accept it.
> 
> we have to get the noise out. I don't care how but we have to. It's a huge
> wast of our development resources if we developers do the first level
> support. I have never encountered any successful company where the
> developers do the first level support. If we want to be professional, we
> have to be
> professional. That means first level support out of the developer tools.
> 
> There are areas of KDE where it is still working, but applications like KWin
> and Plasma Desktop need a first level support in front of it. KMail is
> already for a more advanced user group, so it's not perfectly comparable.
> Kdelibs is completely only used by developers, so perfect audience.
> 
> > > >  And if there pitfalls, common problems with your application in
> > > >  certain
> > > > 
> > > > setups, document them
> > > 
> > > Yes, best in a blog. /sarcasm
> > 
> > Sure. :) BTW, if you refer to my Akonadi blogs, that content is more or
> > less also in the userbase wiki and in KMail's manual nowadays. And seen
> > it being used as a reference on IRC and user mailing list by others. So
> > the information spreads out. And google also finds it.
> > 
> > > > and distribute to as many channels as possible
> > > 
> > > So users can search there for the solution? In a way hoping that their
> > > circles somehow match the developer ones?
> > 
> > Yes.
> > 
> > > And you think, that's what they'll do instead pressing "report bug" in
> > > Dr.Konqi? (what *is* the expected behavior and will usually take the to
> > > the right bug in short time.
> > 
> > Maybe not for crashes, but there are more than crashes in applications.
> > I know, that I google many times if I have a problem. But I'm also a
> > developer, so users might not do that. But still, keeping things "secret"
> > won't help, you need to tell the solution everytime when somebody has a
> > problem.
> > 
> > > Developers and experienced users will google the issue up anyway.
> > > Ubuntu users won't. They think "OMG, >>>I<<< have a problem. Best report
> > > it and ask to get help"
> > 
> > I'd skip this, as I don't want to categorize users. Certainly there are
> > some hard to deal with, but this just proves what I said: you have to
> > accept the situation.
> 
> no, we have to improve the situation! Accepting it means surrendering. It
> means accepting that Plasma has reached the state where nobody cares about
> the bugtracker, because it's not useful anymore. KWin is very close to that
> state...
> 
> > > > that large as kmail though), I only remember one case when the user
> > > > left
> > > > upset.
> > > 
> > > This is not about the user being upset. That's the users problem ;-)
> > 
> > Questionable. It is about an atmosphere problem in the community.
> > 
> > I'm all for a better tool, that's not a problem, but blaming the users for
> > reporting everything they have in mind is not a solution. They have a
> > problem, that's why they turn to bugs.kde.org, and every problem you have
> > is the biggest and most important on earth, no?
> 
> yes, of course, we have to help the users. But they need to get a tool for
> user support, not a tool for developer communication. We need a first-level-
> support to help the users. Developers are the third-level-support.

I doubt that there are enough people for doing first-level support. Hence it 
falls back on the devs, at least on those areas where nobody else has the 
knowledge/time to do so.

That's what I wrote in my other email. If one expects to get testers for free 
one has to cope with the implications. If one pays for testers one gets all 
the nice stuff, including x levels of support before the dev has to interact 
with the issue etc.

I doubt that  everything that could have been done by devs to enable those 
"triaging" on the forums and mailinglists to help, e.g. scripts to gather 
information, decision trees etc., has been done.

Take nepomuk as an example. Until a few weeks ago there was not even a wiki 
page that documented how one could find the cpu wasting queries. The cpu 
wasting queries are an issue since the beginning of neopmuk, i.e. for years 
and caused lots and lots of useless bug reports simply stating "nepomuk wastes 
cpu and I do not know why".

If people who know how to get the info and what info is needed cannot be 
bothered to document and spread it, how are users or first-level supporters 
supposed to know and act? And how can those devs be surprised that their ratio 
of useless bug reports is high?

Sven