Bob, thanks for the excellent question, because it's something I often
wondered myself as a user before I got here.
Every suggestion or bug report is logged in a tracking database package we
run exclusively for that purpose. Each task, which is the generic name we
give to anything in that database, be it a bug, a suggestion or whatever,
is assigned a unique identifier and assigned a priority. The priority that
task is given will depend on a range of factors, including the perception
of value to new and existing customers if it is a new feature suggestion,
the degree to which any identified bug is considered critical, and the time
and resources involved in fixing or implementation. In the case of a bug,
this needs to be verified internally, something that can be quite a
challenge given different usage patterns and configuration, and obviously
we then need to allocate development time to it.
We give the highest priority to issues which relate to data integrity or
the quality of the hardware, so in the first scenario you quoted, this
would be a hardware-related issue that would essentially cause our hardware
engineers to drop everything until the issue was satisfactorily addressed.
I negotiate with the Development team about what features we can include
into the next release within agreed timeframes. That is to say, I have
goals for when I would like releases to come out. Like any software
company, sometimes there is slippage but with appropriate planning and
realistic setting of expectations we hope to minimise this.
When it comes to thinking about the next release, I sit down with
Development and we take a look at everything that's in that database. We
work out what we can usefully do with given resources and time pressures,
and from that I reach an agreement with Development with regard to what
they will produce for the forthcoming release.
So it is quite a precise process, and while we can't give everyone
everything they want immediately, feedback is definitely noted and logged
in a manner that ensures it doesn't get lost.
Hope this helps.
Jonathan Mosen
BrailleNote Product Marketing Manager
Pulse Data International Ltd
DDI: +64-3-373-6192
Fax: +64-3-384 4933
Mobile: +64-21 466 736
Email: [EMAIL PROTECTED]
Internet: www.pulsedata.com
bob
<[EMAIL PROTECTED]
.net> To
Sent by: List Braillenote
braillenote-bounc <[EMAIL PROTECTED]>
[EMAIL PROTECTED] cc
.com
Subject
[Braillenote] a PDI question
17/11/2003 09:54
p.m.
Please respond to
Braillenote List
<[EMAIL PROTECTED]
.pulsedata.com>
I would appreciate it if someone from PDI could answer the following
question.
What is the process at pulsedata to process a bug report reported here on
this list?
Let's take three scenarios, none of which are true:
1 A serious bug is reported: When x happens my BrailleNote falls
apart in my hands.
2 A problem for everyone is reported. For example, when I press
dot 1 and enter my BN says "stop it!"
3 Something is asked for by several members of this group
(something that works, but could work better.) For example, the ability to
use the review commands in the on-line manual withou having to press the
spacebar. Hey wait: this one is true!
I am just curious about the journey that a bug report takes going from an
idea to an enhancement.
Thanks,
Bob
___
To leave the BrailleNote list, send a blank message to
[EMAIL PROTECTED]
To view the list archives or change your preferences, visit
http://list.pulsedata.com/mailman/listinfo/braillenote
