--nextPart1494991.Pk2qSFaQDd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 24 February 2012 19:32:10 Andras Mantia wrote: > On Friday, February 24, 2012 06:10:23 PM Thomas L=C3=BCbking 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 th= eir > > 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 so= me 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 solutio= n > (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 manageme= nt=20 system - e.g. forums.kde.org. Only if the supporters figure out that th= ere is=20 a real bug, they will open a bug report. This is high filtered, all the= =20 information present. Just to give you a feeling about what we are talking in KWin:=20 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=20 with reviewboard etc. etc. maybe max half an hour. To search the bugtra= cker to=20 find a fixable bug I need as long as filtering the spam, that is after = reading=20 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=20 I find a fixable bug. It annoys me and I mostly stopped using the bug t= racker=20 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 attachin= g a > > trace?) > > b) change the DEFAULT message order to "description" -> newest -> o= ldest, > > users (passing by) will not edit bugzilla presets (if ever they kno= w > > about) >=20 > With this I agree, we could tweak the defaults. >=20 > > c) make the "description" (that is the original report message) edi= table >=20 > > 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 wi= th 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 abou= t and I=20 don't have to scroll through half an hour of user things to figure out = again=20 what it was about. >=20 > > > If you wish to organize your tasks, I'm afraid you should do in a= nother > > > 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 us= er with > > a problem. >=20 > This was a suggestion for the project, not the individual. Bugzilla i= s 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=20 it is a task organizer. >=20 > > > If you don't like users reporting bugs, close the product for bug= zilla, > > > ignore the users, and do what you want. > >=20 > > Nonsense. This is not about "I don't like hearing about bugs" but a= bout "i > > don't like my bugs being spammed" >=20 > 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 car= e > 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 h= uge=20 wast of our development resources if we developers do the first level s= upport.=20 I have never encountered any successful company where the developers do= the=20 first level support. If we want to be professional, we have to be=20 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=20 and Plasma Desktop need a first level support in front of it. KMail is = already=20 for a more advanced user group, so it's not perfectly comparable. Kdeli= bs is=20 completely only used by developers, so perfect audience. >=20 > > > And if there pitfalls, common problems with your application in = 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 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. >=20 > > > and distribute to as many channels as possible > >=20 > > So users can search there for the solution? In a way hoping that th= eir > > circles somehow match the developer ones? >=20 > Yes. >=20 > > 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 th= e to > > the right bug in short time. >=20 > Maybe not for crashes, but there are more than crashes in application= s. > 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 "sec= ret" > won't help, you need to tell the solution everytime when somebody has= 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 r= eport > > it and ask to get help" >=20 > I'd skip this, as I don't want to categorize users. Certainly there a= re some > hard to deal with, but this just proves what I said: you have to acce= pt the > situation. no, we have to improve the situation! Accepting it means surrendering. = It=20 means accepting that Plasma has reached the state where nobody cares ab= out the=20 bugtracker, because it's not useful anymore. KWin is very close to that= =20 state... >=20 > > > that large as kmail though), I only remember one case when the us= er 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 user= s 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=20 user support, not a tool for developer communication. We need a first-l= evel- support to help the users. Developers are the third-level-support. But I think I repeat myself here :-) Cheers Martin --nextPart1494991.Pk2qSFaQDd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk9Hzg8ACgkQqVXwidMiVrrxmgCeNX+frGmCgWFRbUtFVoCGWnJc TZYAn2K5R09Nqisn4kZralJBV0DdzLCi =ufih -----END PGP SIGNATURE----- --nextPart1494991.Pk2qSFaQDd--