This is my entry for the Software Carpentry Issue Tracker category. It includes:
A specification in the form of an online Tracker Users Guide. (That document accounts for just under my quota of 5000 words for the specification phase of the software carpentry competition.)
Tracker design diagrams, including several use case and a few issue state diagrams.
A prototype tracker we have developed at Digital Creations, which we have developed using Zope. Anyone can visit and play with this tracker. Contact me ([email protected]) if you wish to try out the supporter role. For more about how we happen to have this prototype, see below.
This entire documentation package is available at http://www.zope.org/Members/klm/SoftwareCarpentry/.
Recent development - the prototype tracker is available as a zope product, with public CVS checkout. It also has elaboration on the development desires i mention below - see my Tracker wiki.
We happen to be able to provide fairly substantial designs for an Issue Tracker, and even a substantial working prototype, because we've been working for a while on the tracker for internal and zope community use.
While we have released the tracker to a few eager people in the Zope community, and we're interested in releasing it more generally when the principal developer (me) is freed up from a consulting gig, there are unimplemented features, and in the course of using it we've discovered some additional features we now desire, given the capabilities we enjoy in our prototype:
Currently issue creation and responses are submitted only via the web. Notices about new posting are sent to all concerned parties via email, but we would like to provide for purely email submissions, as well.
We see a need to be able to coordinate numerous distinct trackers, which we're considering doing with some kind of federation.
At Digital Creations, part of our business is support, both of commercial (paying) customers and of open source participants in the development of our wares. This means we provide support for diverse communities, having varying support requirements modulo concerns like privacy levels and topic focus, and, generally, distinct topic domains.
These distinct purposes can call for separate trackers to simplify operation for the specific audiences. However, this simplification can complicate the job of support management, who need to coordinate supporter efforts across support efforts, and also can complicate the mining of knowledge from the established issues across these efforts.
We see addressing this with a federation layer over the trackers, enabling consolidation of search, reporting, and supporter assignment while maintaining decoupling of the subject domains.
Currently the workflow is hardcoded as described in the documentation. Digital Creations has incepted a project to develop a general framework to provide workflow services, which the tracker would use, but that project is currently on the back burner in deference to specific consulting jobs.
An optional tracker operating mode where the privilege to submit an issue is goverend by "tickets" which tracker clients purchase or are granted (say, as part of a favor economy, where people solving problems get tickets entitling them to submit issues for their own problems).
Here is our initial identification of tracker ticket use cases.
The tracker prototype UI is too busy, the exhibition of issues could be improved by use of a detail-exposure control mechanism like the tree-tag, and user-controlled sorting of the issues is not yet implemented, etc.
