Chapter 5. Other Issues

  1. 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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).

  7. "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.

  8. 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.

  9. 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).

  10. 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.

  11. 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.