The current design queries reports by doing a brute-force search of the existing text files. This is quite inefficient and could be augmented with a simple index (ie the administrator defines which fields are likely to be searched, and YakTrack generates an index based on these fields).
Short of simply adding lines to a HISTORY element or some such, YakTrack does not support threaded discussions or some other aspects of "groupware". But that is not its intent-- its intent is to be a simple solution for issue tracking, not a "Swiss Army Chainsaw" for groupware. Those needing threaded discussions might want to set up a local news server; this is not an attempt to be flippant, but rather an attempt to keep the application focused on a single (and simple) goal.
The existing design does not address delegation of responsibility with issues, because it is remaining as issue-neutral as possible (in other words, administrators should not be forced to deal with this, and individual users may find it irritating). However, it should be easy to write scripts which pass reports meeting certain criteria to individuals; this could be implemented as a simple table (or XML file) which matches query-style criteria to email addresses, and patched into the file command to send mail to workers automatically as reports are filed.
Security is not addressed in the current design except to the extent that immediate users have control over everything and remote users have control over very little. To an extent, the configuration management software will have an impact on security, and provides a nice cushion in case vital information is "destroyed" (as it should be recoverable via CM). We hazard that for many development projects, stronger security than that provided by CM tools may not be necessary, although it should be straightforward to modify the email-gateway command to disallow certain subcommands from certain email addresses, or for the web gateway to do something similar.
The second reason that security is not addressed more aggressively is that the security needs of different organizations are often, well... different. It would be unfair to force different organizations into a given security model without more input from potential users.
The system only handles simple XML-compatible inputs. Anything else must be saved as an attachment in a subdirectory in the repository. While this is flexible, it may irritate users who need non-latin alphabets or other input needs.
Translation between system-dependent formats (CR/LF) conversion is handled by the configuration management software (CVS, for example, is a champ at this, transforming text files transparently).
"Intelligent searches", as per the SC Track suggested requirements list, are not implemented (keyword-only searches are implemented as discussed above). Adding more comprehensive search capabilities would certainly be possible by extending the query command.
Statistics collection is not specifically addressed by the current design except as a possibility for a local extension to the YakTrack immediate tool. However, statistics collection is extremely important, and could be done by extending or using the query command to find defects with a status of "open" vs "closed" and present a summary, for example. A very ambitious implementation of such a command might script the configuration management software to track these metrics over time, showing a "lifecycle" view of the desired metrics. We believe that this is preferable (although much less efficient) than having YakTrack keep additional information around on changes, past metrics, etc.
We appreciate that hand-editing DTDs is not something the average user would particularly enjoy playing with; users and administrators would rather use a tool rather than spend hours configuring it (although we must point out that editing a single DTD in the issue repository is arguably simpler than, say, editing the /usr/local/share/gnats/gnats-db/gnats-adm/categories file and remembering to run the mkcat program.... Thus YakTrack would ship with a standard template for common issues (defects, requirements, wish lists, etc) which could work out-of-the-box. In addition, the focus on simple DTDs makes editing only a minor hassle (rather than deciphering nested layers of elements, the simple DTDs handled by YakTrack will only be one element "deep" at any given point).
XML allows linking to other data sources, and this will be supported to an extent with linking reports to attachments, other reports, etc. However, the mechanics of this have not been fully explored in this submission.
Only "simple" XML DTDs are supported at least initially (see the "What do you mean by "simple" DTD?" sidebar). This has a few disadvantages (it constrains the freedom of the issue repository administrator, cannot handle some types of input, and particularly forces submissions into a linear, straightforward format), but has several advantages. First, issue reports should be easy for humans to deal with; the average issue reporter is going to feel that a branching, multilayered issue submission format is too cosmic to use, and will wish for something simpler anyway. Second, the XML standard, while simpler than SGML, is still extremely complex. Attempting to allow all of it at once would make YakTrack a formidable application indeed. Third, a simple format such as we describe could be MUCH more easily parseable by a front-end into a text-based or web-based submission form. Fourth, while it does not include all the power of XML, it could in the future; the groundwork has been laid. It would be much more traumatic to move to XML if we had chosen a "proprietary" format for issues.
What do you mean by "simple" DTD?
XML handles document templates in the form of Document Type Definitions (DTDs), composed of elements and attributes. Elements can be composed of groups of other elements, which makes for powerful document structuring -- and parsing headaches for YakTrack. And the fact is, probably 90% of tracking system users would not benefit from the full complexity of XML (and would in fact appreciate simplicity rather much more!).
To ameliorate this confusion, YakTrack is initially planned to handle only "simple" DTDs which follow a few rules: Only the "root" element of the DTD can contain other elements, and it can only contain a fixed number of them, with no choice groups, optional elements, entities, or multiplicity operators. In other words, if the root element of a DTD was called "DEFECT", the following would be a valid description of the element:
But the following would not:
EMPTY elements are allowed, and elements can have attributes (although initially, only CDATA and enumerated attributes will be allowed).
This means that YakTrack-compliant DTDs are never more than one element "deep" and contain a fixed number of elements-- a broad-but-shallow decision tree that is conceptually easy to deal with. Lest XML fans believe that such a restricted subset of XML would prove useless, keep in mind that it paves the way for further expansion, and that the functionality of a GNATS report could probably be contained in the following DTD (for demonstration only-- this may not be syntactically correct):
As YakTrack matures, these restrictions may be relaxed; in particular, having optional elements or repeating elements could be very handy for storing history lists, etc. In the mean time, this simplified type of DTD has many benefits, not the least of which is that it's much easier to translate into a front-end; a web gateway, for example, could take the above, turn each enumerated attribute of Defect into a drop-down list box, turn each #PCDATA element into a text box, and have a ready-made form without too much difficulty-- adding tremendous flexibility to the YakTrack application suite!