[1926] in Release_7.7_team
re: How can we better acknowledge Athena bug reports?
daemon@ATHENA.MIT.EDU (oliver thomas)
Wed Sep 15 19:05:06 1999
Message-Id: <199909152304.TAA146600@mufasa.mit.edu>
To: Bill Cattey <wdc@MIT.EDU>
Cc: release-team@MIT.EDU
Cc: oliver thomas <othomas@MIT.EDU>
Reply-To: oliver thomas <othomas@MIT.EDU>
In-Reply-To: your message of Wed, 15 Sep 1999 18:22:00 -0400.
<Urs1k8gGgE6e1AZQk0@mit.edu>
Date: Wed, 15 Sep 1999 19:04:58 -0400
From: oliver thomas <othomas@MIT.EDU>
bill,
> It occurs to me that, properly speaking, the task of saying "We received
> your report, and are sorry you were inconvenienced." is a SUPPORT issue.
the task of acknowledging a message is, generally speaking, the
responsibility of the entity processing the message, whoever that ends up
being. more generally speaking, making the customer believe that her
message is not lost in a black hole is good customer relations. you could
argue that good customer relations is the sole responsibility of the
support process, but i would have to then disagree with you.
what is the desired outcome here? it seems a little premature to suggest
an action item like consultant responses to bug reports without being
clear on what the goal is.
if our goal is to provide a stock acknowledgement to users sending in bug
reports to give them that warm and fuzzy feeling then no human
intervention is required. there is really no substance behind the reply.
we can just modify or wrap dsmail to send back a stock response.
if our goal is to provide real feedback to users and attach some degree of
tracking and accountability to bug reports, then you are setting whoever
you make the mouthpiece for this up for a fall if you don't attach a real
process at the backend.
finally, if our goal is to create a bug tracking process, and to do so by
having athena consultants read and acknowledge bug reports followed by
monitoring their progress and/ or handing them off to developers to fix,
that would be an interesting proposal worth discussing. issues that come
to mind are the need for better information on who does what in dev, how
to follow up on progress once the hand-off has been made, and so on.
all of this has come up in past bug tracking discussions. perhaps it is
time to make a real project out of it.
oliver
