bugzilla situation

[Kevin Krammer]

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.

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.
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.

> > 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.

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.

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.

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.

Cheers,
Kevin

[1] I know a couple of developers who read their project's user mailinglist 
through a newgroup interface and have local scoring rules that keep all 
postings hidden unless 100 points are reached.

This can be achieved by any combination of things happending, e.g. the person 
themselves posting (gets 100 points instantanioulsy), two postings from 
another developer (50 points for posting by any other developer), etc.

They can temporarily or permanently upscore certain other posters, explicitly 
hide or unhide threads, etc.

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120226/8bc55235/attachment.sig>