Sorry for the silence, Wednesday I went home early and I've been home since. I picked up a wicked cold and haven't been able to think straight.
Thanks robocoder for taking a look at the whole of DefectTrackingPatterns, I welcome your comments. Until I get my head clear, here's a short list of my brain dump of things that a good bug tracking system ought to have.
- Users can split items (e.g. when one item actually describes two separate issues) or combine them (e.g. when several contributors submit identical items)
- Users can associate items in groups and dependencies.
- Old discussions or issues archived, indexed, and searched. When and how does the system and/or its users identify submissions or discussions that are re-raising old topics or issues?
- Issues, and changes in the state of issues, are connected to the use of other tools, such as checking source code in or out
- Users are able to perform intelligent searches on issues, i.e. something more sophisticated than searching for keywords in the bodies of issues
- URL-style link to defect in other documents, for example http://bugzilla.mozilla.org/show_bug.cgi?id=100000
- Allow defects to have dependencies on other defects, use to create "tracking defects" and "release requirements" defects that refer to other defects that must be closed before the parent can be closed.
- Allow users who are neither the submitter or assigned developer or admin to put themselves on a list of users to CC email on changes (watch list)
- Clearly differentiate between defects and RFEs
- Able to identify and push issues that are really support questions to the appropriate persons/tools
- Use with any web browser on any O/S
- Allow anyone on the email-on-change list to adjust which events they wish to get email about; then the system can by default be configured to email on all non-trivial events and users can turn the noise level down