Am Freitag, 24. Februar 2012, 18:51:11 schrieb Martin Gr=E4=DFlin: > On Friday 24 February 2012 19:32:10 Andras Mantia wrote: > > On Friday, February 24, 2012 06:10:23 PM Thomas L=FCbking wrote: > > > Am 24.02.2012, 09:44 Uhr, schrieb Andras Mantia = : > > > > Bugzilla is not a to-do list, it is for what else... a bug (and= > > > > wishlist) > > > > reporting tool for users. > > >=20 > > > 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) > >=20 > > 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? > >=20 > > If you can moderate it, it means you have time and resource to do = it, so > >=20 > > you could have done until now as well. The rest is not a real solut= ion > > (maybe Dr. Konqui is, but then you will also lose valid reports). > > Any other suggestion? >=20 > -> first level support >=20 > issues are not opened on the bug tracker but in a user support manage= ment > 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, al= l the > information present. >=20 > 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 >=20 > to filter out ten "spam" reports I need an hour. To fix a simple iss= ue 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. >=20 > So consider I have an hour I want to spend for bug fixing - it is gon= e > 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? >=20 > > > 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 attach= ing a > > > trace?) > > > b) change the DEFAULT message order to "description" -> newest ->= > > > oldest, > > > users (passing by) will not edit bugzilla presets (if ever they k= now > > > about) > >=20 > > With this I agree, we could tweak the defaults. > >=20 > > > c) make the "description" (that is the original report message) e= ditable > >=20 > > > by component owners ANYTIME - this here: > > Bug editing/cleaning up makes sense (still doesn't solve the ORIGIN= AL > > 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 exampl= e. But > > you still have the problem that you need to spend time to do that. >=20 > which is fine if afterwards I have a bug report stating what it is ab= out and > I don't have to scroll through half an hour of user things to figure = out > again what it was about. >=20 > > > > If you wish to organize your tasks, I'm afraid you should do in= > > > > another > > > > tool. > > >=20 > > > 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. > >=20 > > 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 ent= ries > > might refer to bugzilla bugs. >=20 > have a look how Mozilla uses bugzilla (IIRC it is developed by Mozill= a). > There it is a task organizer. >=20 > > > > If you don't like users reporting bugs, close the product for > > > > bugzilla, > > > > ignore the users, and do what you want. > > >=20 > > > Nonsense. This is not about "I don't like hearing about bugs" but= about > > > "i > > > don't like my bugs being spammed" > >=20 > > See above and my mail. IMO you can't avoid that with the userbase w= e have. > > You have to live with it. Of course, I was ironic, and I hope nobod= y will > > do that, but I know there are developers from teams who don't reall= y care > > about bugzilla reports. That's fine, I can accept it. >=20 > 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 too= ls. >=20 > There are areas of KDE where it is still working, but applications li= ke KWin > and Plasma Desktop need a first level support in front of it. KMail i= s > already for a more advanced user group, so it's not perfectly compara= ble. > Kdelibs is completely only used by developers, so perfect audience. >=20 > > > > And if there pitfalls, common problems with your application i= n > > > > certain > > > >=20 > > > > setups, document them > > >=20 > > > Yes, best in a blog. /sarcasm > >=20 > > Sure. :) BTW, if you refer to my Akonadi blogs, that content is mor= e 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. > >=20 > > > > and distribute to as many channels as possible > > >=20 > > > So users can search there for the solution? In a way hoping that = their > > > circles somehow match the developer ones? > >=20 > > Yes. > >=20 > > > And you think, that's what they'll do instead pressing "report bu= g" in > > > Dr.Konqi? (what *is* the expected behavior and will usually take = the to > > > the right bug in short time. > >=20 > > Maybe not for crashes, but there are more than crashes in applicati= ons. > > 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 "s= ecret" > > won't help, you need to tell the solution everytime when somebody h= as a > > problem. > >=20 > > > 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" > >=20 > > 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. >=20 > 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 t= o that > state... >=20 > > > > that large as kmail though), I only remember one case when the = user > > > > left > > > > upset. > > >=20 > > > This is not about the user being upset. That's the users problem = ;-) > >=20 > > Questionable. It is about an atmosphere problem in the community. > >=20 > > I'm all for a better tool, that's not a problem, but blaming the us= ers 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 yo= u have > > is the biggest and most important on earth, no? >=20 > yes, of course, we have to help the users. But they need to get a too= l 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. Hen= ce it=20 falls back on the devs, at least on those areas where nobody else has t= he=20 knowledge/time to do so. That's what I wrote in my other email. If one expects to get testers fo= r free=20 one has to cope with the implications. If one pays for testers one gets= all=20 the nice stuff, including x levels of support before the dev has to int= eract=20 with the issue etc. I doubt that everything that could have been done by devs to enable th= ose=20 "triaging" on the forums and mailinglists to help, e.g. scripts to gath= er=20 information, decision trees etc., has been done. Take nepomuk as an example. Until a few weeks ago there was not even a = wiki=20 page that documented how one could find the cpu wasting queries. The cp= u=20 wasting queries are an issue since the beginning of neopmuk, i.e. for y= ears=20 and caused lots and lots of useless bug reports simply stating "nepomuk= wastes=20 cpu and I do not know why". If people who know how to get the info and what info is needed cannot b= e=20 bothered to document and spread it, how are users or first-level suppor= ters=20 supposed to know and act? And how can those devs be surprised that thei= r ratio=20 of useless bug reports is high? Sven