--nextPart2882591.nf0CvkeDKX Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Friday, 2012-02-24, Martin Gr=E4=DFlin wrote: > 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 : > > 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? >=20 > -> first level support We do have plenty of such channels and they do tend to work pretty well for= a=20 wide range of questions (not necessarily problems). Some questions (again not necessarily problems) require either understand c= ode=20 (and of course find the relavant portions first) or in some cases even "big= ger=20 view" of things. I guess it all boils down on how you define first level. For me that's all = kinds=20 of things that can be solved by users themselves, e.g. finding the answer=20 through experiementation or through easily findable public documentation. Anything beyond that, e.g. requiring understanding of developer level=20 documentation or reading files in the respository (code, READMEs, etc) is I= MHO=20 already second level. This or rather the transition between the two is what we currently lack mos= t. > > > > 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 abo= ut > > > "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 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 tools. Separate tools make it harder to move/share context. In some cases it even requires manual opcying, e.g. of information between = two=20 contexts which should be the same. This approach is similar to doing a backup by manually copying new/modified= =20 files to the backup location instead of using some synchronisation tool. I think introducing another separate tool is the least preferable solution.= It=20 will just increase the work on those who currently weed out the important=20 entries. > > 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? >=20 > 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 disagree. =46or one because I think the level we are missing or have understaffed is = level=20 two and second because the real issue is losing all information when crossi= ng=20 a level threshold, especially when crossing into third level. Lets assume the issue tracking system is closed and only allows write acces= s=20 to developers and accredited second level support people (e.g. like the=20 triagers). Now a user with a problem shows up in some first level support channel, e.g= =2E=20 forum.kde.org or a mailinglist. After a while it is clear that the problem cannot be solved by user communi= ty=20 support. Problem at this stage is that there is not mechanism or rules on h= ow=20 to esacalte to second level, so this transition already requires second lev= el=20 to constantly monitor first level discussions to determine when that partic= ular=20 stage is reached. Lets assume that we are lucky and someone with access to and understanding = of=20 code happens to come across this halted thread. They might not be able to solve it either but maybe exhaust more options th= at=20 the original user could try. Under our initial assumption of a closed issue tracking system we do have=20 mechanism and rules for transition (yay!) but we now lose all context (doh!= ). You end up with two contexts, have to manually copy information back and=20 forth. And there is a significant effort involved in creating the second=20 context, because someone has to wade through all information in the first=20 context and selectively copy/rewrite bits and pieces. I agree that this second context is ideal for consumption for developers, i= =2Ee.=20 being reduced to only the required information, but if we already have a=20 scalability problem with the current approach, I don't see how that can sca= le=20 either. IMHO the only viable way is to keep the same context and have apply filteri= ng=20 and highlighting such that what one sees depends on what one needs to see. E.g. say second level is able to attach scoring information to information= =20 inside the first level context and, when the involvement of third level bec= omes=20 necessary, just flag the context for "needs third level review". At this point third level can already use the second level score to only lo= ok=20 at a reduced problem, but is potentially available to expand. If we assume a separate score for third level, developers of the same team= =20 could even reduce the required reading even further, even if the respective= =20 individual will not be the one working on a solution. Basically just a more advanced implementation of what usenet clients alread= y=20 provided [1] almost two decades ago. Cheers, Kevin [1] I know a couple of developers who read their project's user mailinglist= =20 through a newgroup interface and have local scoring rules that keep all=20 postings hidden unless 100 points are reached. This can be achieved by any combination of things happending, e.g. the pers= on=20 themselves posting (gets 100 points instantanioulsy), two postings from=20 another developer (50 points for posting by any other developer), etc. They can temporarily or permanently upscore certain other posters, explicit= ly=20 hide or unhide threads, etc. =2D-=20 Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring --nextPart2882591.nf0CvkeDKX 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) iD8DBQBPSiwJnKMhG6pzZJIRAqZCAJ0RH11cj4HPDZp3emUO7GOJOUtp5wCePefn ylR60h4O88023VdWSqax7xo= =YakZ -----END PGP SIGNATURE----- --nextPart2882591.nf0CvkeDKX--