bugzilla situation

[Martin Gräßlin]

On Sunday 26 February 2012 13:56:41 Kevin Krammer wrote:
> On Friday, 2012-02-24, Martin Gräßlin wrote:
> > 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>:
> > >  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
> 
> We do have plenty of such channels and they do tend to work pretty well for
> a wide range of questions (not necessarily problems).
> 
> Some questions (again not necessarily problems) require either understand
> code (and of course find the relavant portions first) or in some cases even
> "bigger view" of things.
> 
> 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.
> 
> 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
> 
> This or rather the transition between the two is what we currently lack
> most.
> > > > > 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.
> 
> Separate tools make it harder to move/share context.
> In some cases it even requires manual opcying, e.g. of information between
> two contexts which should be the same.
I personally doubt the usefulness of information from first level support 
stage for higher levels. That is I have often considered to open new bug 
reports after the support has been done with the information needed for 
developers and mark the support request bug report as a duplicate. That would 
involve the same level of duplication.

What's for me important is to have the link to the original first level 
support request.
> This approach is similar to doing a backup by manually copying new/modified
> files to the backup location instead of using some synchronisation tool.
> 
> I think introducing another separate tool is the least preferable solution.
> 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 detail. 
What matters is that the developers get the information they need without 
being scattered in support requests.

I think I'll write a blogpost later on how I consider this could work :-)
> 
> > > 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 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.
> 
> Lets assume the issue tracking system is closed and only allows write access
> to developers and accredited second level support people (e.g. like the
> triagers).
> 
> Now a user with a problem shows up in some first level support channel, e.g.
> forum.kde.org or a mailinglist.
> 
> 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 mechanism or
> rules on how to esacalte to second level, so this transition already
> requires second level to constantly monitor first level discussions to
> determine when that particular stage is reached.
well obviously the first level support has to notify second level support that 
it is unable to solve a problem. This could be done even automatically by e.g. 
showing all unresolved threads in the forum.
> 
> Lets assume that we are lucky and someone with access to and understanding
> of code happens to come across this halted thread.
> They might not be able to solve it either but maybe exhaust more options
> that the original user could try.
> 
> 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!).
> 
> You end up with two contexts, have to manually copy information back and
> forth. And there is a significant effort involved in creating the second
> context, because someone has to wade through all information in the first
> context and selectively copy/rewrite bits and pieces.
> 
> I agree that this second context is ideal for consumption for developers,
> i.e. being reduced to only the required information, but if we already 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 bugtracker is 
abused for user support which it is unsuited for (I will elaborate that point 
in the blog post).

In case of kwin there are so few issues which would have to be forwarded to 
the developers that I doubt that this would introduce scalability problems.
> 
> 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 one
> needs to see.
> 
> E.g. say second level is able to attach scoring information to information
> inside the first level context and, when the involvement of third level
> becomes necessary, just flag the context for "needs third level review".
> 
> At this point third level can already use the second level score to only
> 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 respective
> individual will not be the one working on a solution.
> 
> 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 start to 
use bugzilla properly. But it boils down again to the problem that bugzilla is 
unsuited for user support.

So the big question in the end is, whether we consider bugzilla to be a tool 
for user support or for tracking developer information.

My personal opinion is that bugzilla is unsuited as a user support tool and 
because of that we need solutions to integrate first level with higher level 
support. What I see is that we need to have different ways to provide first 
level support to the users. Not all users like forums, not all like IRC, etc. 
So we need to find a proper solution to not lose the context as you write, if 
and only if that is a real issue at all.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120226/5d9d96f5/attachment.sig>