How are bugs and feature enhancement requests handled?

Last Revision Date: 6/22/2015

This article documents how bugs and feature enhancement requests are handled. 

As with any piece of software or firmware, bugs and useful feature enhancements are often discovered during the course of normal usage. We consider a number of factors when prioritizing feature enhancement requests and bugs that are submitted, including the following (in no particular order):

• • General severity: e.g. does the bug cause total system crashes?
  • Implementation difficulty: e.g. does fixing the bug require changes beyond the firmware, such as software/hardware modifications?
  • Maintenance requirements: e.g. will a new feature require excessive time to maintain through future versions?
  • Resources required: e.g. resources can include time, money, and people.
  • Products affected: e.g. does this bug affect multiple product families, multiple models within a family, or a single model?
  • Impact across products: e.g. is the feature easily transferable, so that it can be implemented across products?
  • Customer demand: e.g. is there a large number of existing customers asking for a feature?

For example, development resources are a limited commodity, and any resources that are allocated to adding a feature or correcting an issue must be taken away from other projects. For these reasons, a feature, though useful, may not be implemented quickly or at all if customer demand is low and the resources necessary to implement it are high.

Currently, bugs and feature enhancements are tracked using Bug numbers. When a customer submits a bug or feature enhancement, they will be issued a bug number by which the issue is tracked. If a customer wishes to inquire about the progress of a bug or enhancement, they may use this number to refer to the project in question to ensure a quick response. Users will normally be notified by email when a resolution is achieved.