Bug or Feature Request?

I started to write a description of how to report bugs, but found that others have done a much better job than I could. Take a look at the following:

Simon Tatham's How to Report Bugs Effectively

http://bugs.php.net/how-to-report.php (written specifically for PHP but the general principles apply to any software you use).

With that out of the way, here's a problem of a different sort:

When is a problem with xTuple ERP a bug and when is it a feature request? Most software companies get lots of queries asking, "Why doesn't the program do X?" or "Why does it do Y?" xTuple is no exception.

We frequently discuss with customers whether a report of missing or unexpected behavior should be considered a bug or a feature request.  Practically speaking there's a huge difference between the two, regardless of the amount of work involved in addressing the issue.

The distinction between them is that a bug is an unintended behavior or lack of behavior, while a feature request is a desired change to intended behavior. There is such a thing as a "design bug", where the intended behavior is undesirable for some reason, but that's a topic for another day.

• If the application crashes, there's a bug - the application should never crash.*
• If you click the Save button and the data don't get saved, there's a bug.
• If you want a new report that the application doesn't provide, it's a feature request.
• On the other hand, if there is a print button on a window but no report definition behind it, there's a bug.
• If you want a payroll module, it's a feature request (as of 2009:-).

Sometimes the distinction isn't so clear.

• Is adding a column to an existing report a feature request or a bug?
• What about performance? What is the threshhold at which a performance problem crosses from being a feature request ("please make this faster") to being a bug ("nobody should have to wait this long")? There is no single answer because some tasks just take longer than others.
• What about functionality you think "should just be there?" It's a bug because you think any ERP package that doesn't have it is incomplete but it's a feature request because other people can use the software without it.
• Most difficult of all, what do we do when there's a conflict between what some users want and what other users want?

In the end, we have to negotiate when deciding whether certain issues are bugs or feature requests. This negotiation process is not intended to minimize the importance of the request, but rather to prioritize the development and support workload. If a particular issue affects a large number and variety of users, xTuple is more likely to consider it a bug than if the number of affected users is small.

*A note about reporting bugs... A crash has occurred when the application stops running and disappears while trying to do something. When reporting a bug, please don't call undesired behavior a crash unless the application really quits on you. This is a diagnostic term, telling developers to look for a certain type of problem in the application code. If you want to convey urgency, select a severity of major or block.

Another similar diagnostic term is hang (also called a freeze),  which describes cases when the application is still visible but has become unresponsive unexpectedly.