<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=us-ascii" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Holger Freyther wrote:

<blockquote cite="mid:200808131707.20096.zecke@openmoko.org" type="cite">

  <pre wrap="">

yeah, this is work in progress. Stuff like two bug trackers, controlling some 

more fields.. and various other things float through my head and I have to 

organize this first. Other entities fix that by shielding developers and 

putting 1st line support there acting as a multiplexers... but I think 

reaching developers directly can be valuable..

  </pre>

</blockquote>

I second Norbert Hartl on this one.<br>

"Having two different tools raises complexity and lowers collaborative

work. And what do you get from it?"<br>

<br>

As a dev who works with bugzilla internally and with clients, any plans

to separate the devs from the users put a chill through me. I wouldn't

advise trying separate work in to two bug trackers as you lose the

value in the crossover, and a good bug tracker makes it easy to sift

out the important information. In my experience as a dev, any kind of

first line support ends up filtering out most of the useful information

and can't actually provide high quality answers to technical users.

This results in worse software for the user and ironically more support

requests. For everything except phone support, direct contact with the

devs is far superior.<br>

<br>

An idea I came across recently that seems like a good idea is a hybrid

approach, where the devs passively observe <i>all</i> traffic from

users (irc, mailing lists, support mailboxes, bug trackers etc), and

can pick out bits that are useful, and then there are additional people

paid to respond to all the rtfm type questions. That way you get the

best of both worlds. The techies don't have the most valuable

information lost in translation, and the more demanding users get the

support they desire without wasting valuable coding time.<br>

<br>

Tim Abell<br>

</body>

</html>