Building the IDM community....

Hi Sam,

Thanks for sharing your thoughts. For the benefit of others reading this
thread, please let me describe some general tenants of our bug reporting
system as it stands today so I can bridge the internal system to your
external platform.

If a user reports a bug, feature request, or enhancement suggestion to
idm@idmcomp.com, that information is entered into a master database by
product. In the case of a bug report, the issue is first reproduced by our
tier three support staff to ensure it is indeed a bug vs a user error or
system specific/OS limitation. This sometimes involves an email thread with
the user and an import of the users .ini file to verify/duplicate the issue.


Once the issue is indeed found to be a bug, we then categorize the bug
severity and assign a priority. If the problem is severe (such as a macro
fails, app hangs, crash, etc.), it is immediately given to our engineering
division as a HIGH priority for prompt action. Once a fix is developed we
then pass the hotfix to our QA for testing and back to the customer to
ensure that the hotfix resolves the users problem. After this process is
exhausted, we make the hotfix available for public download.

It is important to embrace that the process is very dynamic and the
turnaround for a HIGH priority issue is usually the same or next day if
severe. If it takes us longer, we remain in contact with the user until the
issue is retired. As you can see, posting HIGH priority items in an online
database is quickly overcome by events and not likely actionable within the
boundaries of a collective system as you have suggested.

So what happens to the Medium and Low priority bugs? The same verification
process happens but afterwards, the bug is placed into our tracking
software, sorted by component, priority and assigned to our in-house
development team. They in turn estimate the time it will take to correct the
problem and schedule it as a work item based on priority and existing work
flow. In this light, I can see how you and other users would appreciate
insight into the process

Yes an online bug database would be beneficial. Lifting the corporate veil
and providing visibility to the process would help us communicate with you
and others that desire this information. No objection here. The interactive
voting part is where I take exception as I think a bug fix philosophy
centered on priority is best for our community.

A contemporary example of what you suggest may be what Mozilla calls
Bugzilla. (Visit https://bugzilla.mozilla.org/)

Last thought. In terms of feature and enhancement requests, I think inviting
our users to an online table would be an extension of our existing user
driven development model. In a way we already do this by sorting feature
and enhancement requests based on the frequency of a particular request. If
we see a trend in user requests for more PHP or XML functionality for
example, we then capture that data as a line item for an upcoming release
consideration or development path designation.

As you have suggested, I think by publishing the data we use in the feature
selection/development process would serve the community well as it would add
fidelity of design and provide confirmation to the decisions we make on the
development path of the products.

All great ideas and discussion points. I'll look into this further as time
and resources allow (this is no small task). Thanks again for the dialog
Sam.

-Rich

Hello again Sam. Thanks for the confirmation and your contribution to the
IDM community. It's thought leaders like yourself that steer our decisions
and resource allocations.

Cheers,

-Rich