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 four important criteria—product, component, release, and platform (routing is also determined by issue state and state owner).
For 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.
You need to assign four inboxes for each set of criteria:
• An inbox responsible for verifying issues (typically a QA inbox)
• An inbox responsible for fixing issues (typically a Development inbox)
• An inbox for handling documentation problems (a Documentation inbox)
• An inbox for enhancement requests (typically a product management inbox)
In addition to granular routing rules, Issue Manager requires that you define one routing rule for the product as a whole (i.e., 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 area: QA, Development, Documentation, and enhancement requests. For example, all requests for enhancements for Product X would be 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 (“Defining Product Inbox Settings”), though default routing can be edited as explained in “Adding and Editing Routing Rules”.
Analyzing your organization’s processes
It’s recommended that you 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, “For this component in this release on this platform, who (i.e., which inbox) is responsible for each action (e.g, verifying, fixing, etc.). Then define as many rules as required for the different combinations of these four criteria: product, releases, platforms, and components.
Each rule is entered into the Routing Rules page.
Note the “if-then” layout of the dialog: if an issue matches these conditions—that is, it pertains to a particular release, platform, component, and issue type, then route it to one of the four specified inboxes. (Which of the four inboxes is chosen is determined by the issue’s current state and owner. These concepts and their effects on routing are explained in “State owner”).
The % (percent sign) in the Release and Platforms fields serves as a wildcard character that matches all characters. Using the percent sign by itself in all three fields would be the same as default routing; everything would be routed to the four inboxes specified in the dialog, regardless of values for release, platform, and component.
Another example: Release 4.% in the Release field would match all Release 4 releases: 4.0, 4.1, 4.1.1, etc.
Tip You must specify release, component, and platform names consistently to take advantage of wildcarding.
Once a rule has been saved, it is entered into the Routing Rules page. This dialog is essentially a routing table for a particular product. Alternate product selections can be made using the Product drop-down list at the top of the page.
How to read a routing rule
Here is an example routing rule: send Product A-related issues for all releases and all platforms to the Sonja - Dev inbox when the issue is ready for Development, to QA engineer Mike’s inbox (Mike - QA) when the issue is ready for QA, to the Product A request-for-enhancement inbox (Dan -- Dev (Product A) when an enhancement is submitted, and to Judy’s inbox (Judy -Doc) when a documentation issue relating to the “Show me” component is reported.
Order of rules is critical
The order of rules for a component is critical. Issue Manager routes issues by evaluating their current state (e.g., Unreviewed) against each rule in the table in order. As soon as Issue Manager finds a match, it executes the rule. If there is no match, it routes the issue according to the default rules. Default routing rules are applied only after all other rules for a given product have been applied.