kevin.krammer at gmx.at
Sun Feb 26 12:56:41 GMT 2012
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
> > 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
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
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
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  almost two decades ago.
 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...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel