From kde-core-devel Sun Feb 26 13:59:39 2012 From: Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= Date: Sun, 26 Feb 2012 13:59:39 +0000 To: kde-core-devel Subject: Re: Re: bugzilla situation Message-Id: <24661865.Ab1KFC2TfP () martin-desktop> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=133026485811736 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart3378125.P2Zv8yxOsd" --nextPart3378125.P2Zv8yxOsd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday 26 February 2012 13:56:41 Kevin Krammer wrote: > On Friday, 2012-02-24, Martin Gr=C3=A4=C3=9Flin wrote: > > On Friday 24 February 2012 19:32:10 Andras Mantia wrote: > > > On Friday, February 24, 2012 06:10:23 PM Thomas L=C3=BCbking wrot= e: > > > > Am 24.02.2012, 09:44 Uhr, schrieb Andras Mantia : > > > If you can moderate it, it means you have time and resource to d= o it, > > > so > > >=20 > > > you could have done until now as well. The rest is not a real sol= ution > > > (maybe Dr. Konqui is, but then you will also lose valid reports).= > > > Any other suggestion? > >=20 > > -> first level support >=20 > We do have plenty of such channels and they do tend to work pretty we= ll for > a wide range of questions (not necessarily problems). >=20 > Some questions (again not necessarily problems) require either unders= tand > code (and of course find the relavant portions first) or in some case= s even > "bigger view" of things. >=20 > I guess it all boils down on how you define first level. For me that'= s all > kinds of things that can be solved by users themselves, e.g. finding = the > answer through experiementation or through easily findable public > documentation. >=20 > Anything beyond that, e.g. requiring understanding of developer level= > documentation or reading files in the respository (code, READMEs, etc= ) is > IMHO already second level. agree to everything >=20 > This or rather the transition between the two is what we currently la= ck > most. > > > > > 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" b= ut > > > > about > > > > "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 ho= pe > > > nobody will do that, but I know there are developers from teams w= ho > > > don't really care about bugzilla reports. That's fine, I can acce= pt 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 lev= el > > support. I have never encountered any successful company where the > > developers do the first level support. If we want to be professiona= l, we > > have to be > > professional. That means first level support out of the developer t= ools. >=20 > Separate tools make it harder to move/share context. > In some cases it even requires manual opcying, e.g. of information be= tween > two contexts which should be the same. I personally doubt the usefulness of information from first level suppo= rt=20 stage for higher levels. That is I have often considered to open new bu= g=20 reports after the support has been done with the information needed for= =20 developers and mark the support request bug report as a duplicate. That= would=20 involve the same level of duplication. What's for me important is to have the link to the original first level= =20 support request. > This approach is similar to doing a backup by manually copying new/mo= dified > files to the backup location instead of using some synchronisation to= ol. >=20 > I think introducing another separate tool is the least preferable sol= ution. > It will just increase the work on those who currently weed out the > important entries. actually whether it is another tool or bugzilla is an implementation de= tail.=20 What matters is that the developers get the information they need witho= ut=20 being scattered in support requests. I think I'll write a blogpost later on how I consider this could work := -) >=20 > > > 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. The= y have > > > a problem, that's why they turn to bugs.kde.org, and every proble= m you > > > 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 t= ool 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. >=20 > I disagree. > For one because I think the level we are missing or have understaffed= is > level two and second because the real issue is losing all information= when > crossing a level threshold, especially when crossing into third level= . I don't see you disagreeing with me here. >=20 > Lets assume the issue tracking system is closed and only allows write= access > to developers and accredited second level support people (e.g. like t= he > triagers). >=20 > Now a user with a problem shows up in some first level support channe= l, e.g. > forum.kde.org or a mailinglist. >=20 > After a while it is clear that the problem cannot be solved by user > community support. Problem at this stage is that there is not mechani= sm or > rules on how to esacalte to second level, so this transition already > requires second level to constantly monitor first level discussions t= o > determine when that particular stage is reached. well obviously the first level support has to notify second level suppo= rt that=20 it is unable to solve a problem. This could be done even automatically = by e.g.=20 showing all unresolved threads in the forum. >=20 > Lets assume that we are lucky and someone with access to and understa= nding > of code happens to come across this halted thread. > They might not be able to solve it either but maybe exhaust more opti= ons > that the original user could try. >=20 > Under our initial assumption of a closed issue tracking system we do = have > mechanism and rules for transition (yay!) but we now lose all context= > (doh!). >=20 > You end up with two contexts, have to manually copy information back = and > forth. And there is a significant effort involved in creating the sec= ond > context, because someone has to wade through all information in the f= irst > context and selectively copy/rewrite bits and pieces. >=20 > I agree that this second context is ideal for consumption for develop= ers, > i.e. being reduced to only the required information, but if we alread= y have > a scalability problem with the current approach, I don't see how that= can > scale either. the current scalability problem is caused by the fact that the bugtrack= er is=20 abused for user support which it is unsuited for (I will elaborate that= point=20 in the blog post). In case of kwin there are so few issues which would have to be forwarde= d to=20 the developers that I doubt that this would introduce scalability probl= ems. >=20 > IMHO the only viable way is to keep the same context and have apply > filtering and highlighting such that what one sees depends on what on= e > needs to see. >=20 > E.g. say second level is able to attach scoring information to inform= ation > inside the first level context and, when the involvement of third lev= el > becomes necessary, just flag the context for "needs third level revie= w". >=20 > At this point third level can already use the second level score to o= nly > look at a reduced problem, but is potentially available to expand. > If we assume a separate score for third level, developers of the same= team > could even reduce the required reading even further, even if the resp= ective > individual will not be the one working on a solution. >=20 > Basically just a more advanced implementation of what usenet clients = already > provided [1] almost two decades ago. Most of that would actually be possible using bugzilla if we would star= t to=20 use bugzilla properly. But it boils down again to the problem that bugz= illa is=20 unsuited for user support. So the big question in the end is, whether we consider bugzilla to be a= tool=20 for user support or for tracking developer information. My personal opinion is that bugzilla is unsuited as a user support tool= and=20 because of that we need solutions to integrate first level with higher = level=20 support. What I see is that we need to have different ways to provide f= irst=20 level support to the users. Not all users like forums, not all like IRC= , etc.=20 So we need to find a proper solution to not lose the context as you wri= te, if=20 and only if that is a real issue at all. Cheers Martin --nextPart3378125.P2Zv8yxOsd 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) iEYEABECAAYFAk9KOssACgkQqVXwidMiVroSdQCeN7l3YjqOOPf1h9sLRyVEJQn5 +kYAn2012EjJdj/3tphv01dk4s2Jh5I8 =TKmC -----END PGP SIGNATURE----- --nextPart3378125.P2Zv8yxOsd--