Issue routing is based on rules that you define for a product and its associated releases, platforms, and components. This
rule-based mechanism gives you fine control over the distribution of issues because issues are routed based in part on a combination
of the following criteria:
- Product
- Component
- Release
- Platform
- Issue state
- State owner
You need to assign the following four inboxes for each set of criteria:
- An inbox responsible for verifying issues, which is typically a QA inbox.
- An inbox responsible for fixing issues, which is typically a Development inbox.
- An inbox for handling documentation problems, which is a Documentation inbox.
- An inbox for enhancement requests, which is typically a product management inbox.
Example
All
Product A bugs related to the
Installer component and associated with the
Motif platform can be routed to one set of inboxes, while all
Product A bugs related to the
Installer component for the
Windows platforms can be sent to another set of inboxes.
Default routing
In addition to granular routing rules,
Issue Manager requires that you define one routing rule for the product as a whole, which means default routing. In default routing, issues
for all components, releases, and platforms of a specific product are routed to a designated set of four inboxes.
Each inbox covers one of the following areas:
- QA
- Development
- Documentation
- Enhancement requests
For example, all requests for enhancements for
Product X are directed to the one enhancement request inbox you assign, regardless of the individual component, platform, or release.
Issue Manager uses the default routing rule only when other routing rules do not exist or are not applicable. In other words, default routing
rules are applied only when specific rules do not match or have not been specified.
Default routing is set up during
Issue Manager product setup.
Analyzing the processes in your organization
Analyze the breakdown of work in your organization. Review your list of products, releases, and platforms and consider each
component in turn against this list. Ask yourself questions such as the following:
For this component in this release and on this platform, who, which means which inbox, is responsible for each action, for
example verifying, fixing, and so on?
Then define as many rules as required for the different combinations of the following four criteria:
- Product
- Release
- Platform
- Component