W3C process sets different requirements on the way issues are addressed. What are the tools available to track these issues? How could they be improved?

Tracker is a mySQL-backed tracker by DeanJackson. It is in use by many working groups, and allows tracking on the Web, through IRC and via mail. (example)

ExIT is an XML Schema based solution specifically designed to match the way issues are handled in W3C process; uses W3C Technologies, but lacks a friendly GUI (see below)

RoundUp is open source, python-based, SQL (mySql or postgress) based issue tracker. (example)

W3C Bugzilla (an instance of Bugzilla, an open source project used to track bugs in software projects) is used by some W3C groups to track issues; has a complete UI, but is ill-adapted to the way W3C works; the the WCAG version is better, because better suited to issues tracking ; it has been customized using the Template toolkit; should this customization be proposed as part of W3C Bugzilla install? Ben Caldwell, one of the editors of the WCAG WG notes:

Note that Bugzilla is kind of a double-edged sword in that it provides very powerful tracking and query features for those who are willing to take the time to understand how it works, but it can be a bit overwhelming and confusing for those who have not had opportunity to work with bug/issue tracking systems before or are not willing to take the time to read the documentation and understand how to use it. At this point in time, our issue data is largely maintained by the editors and chairs in our WG, but my hope is that we can get more individuals from the group to begin using it more actively and to help with maintenance over time. However, we have found that its email reminder features about assigned and new issues are very useful for those users who have issues assigned to them and we have recently begun using the system to track incomplete action items as well as open issues.

Also, Max Froumentin has developed an XSLT to produce a Disposition of Comments document directly from a bugzilla database; see the resulting DoC (Member-only).

Jitterbug is a now unsupported issue tracker used by the HTML working group. (example) It works with an email interface (ie, you send mail to a given mailing list, and get an acknowledgement + records the issue in the database); It is written in C, and is difficult to customize. However, the HTML Working Group has exntended it to map to the W3C workflow. It has served that group pretty well for many years. It also has a web front end, and you can submit issues via that if you choose. Finally, the HTML Working Group has a script that will extract issues from the system to auto-generate Disposition of Comment documents. The C source for this is available for any group who wants it. Contact ShaneMcCarron.

The Poorman issues tracker extracts issues from a given mailing list, by using conventions in the subject lines to denote the status of an issue; limited by the threading break between the archives period (could be overridden by longer periods for the archives?), and not very richful to track related information; a Semantic Web technologies based version of this has been developed too

The I18N Issues tracker has a nice UI, a mail interface, based on XML; @@@ Could this the UI needed for ExIT?

email tracking (especially last call comments) with RDF/N3/cwm to spec-prod, cwm-talk 29 Aug 2005 discusses a system used for OWL, webarch, and SPARQL.

A Team-only thread relates to this very specific topic; see if there is more to be extracted from it.

Event Tracking System @@

Ontology

Different groups need different types of issue, allow issues to be in different states, and keep different metadata about issues, and about transitions.

If issues are to be exchanges, a common ontology will help. Also, this would allow describing a specific group's workflow, and allowing a generic issue system to configure itself to handle it.

See: a strawman issue and allowws transtion ontology and a test definition of rules for the Federal Ontology Organization issue tracking.

UI for ExIT

What UI does ExIT needs to be usable by a wider audience? Basically, it lacks a web interface allowing to add or edit an existing entry in an existing ExIT (XML) file. Here is an illustration of the most basic thing that would be needed

(also available as dia file and SVG)

Basically, given an XML file with the issues list:

as of today, there is an XSLT that allows to create several views of the list in HTML
from one of these views (or using a URI trick, such as a ",edit" tool), there should be a way to access a form allowing to edit an existing issue (based on the data contained in the XML file) and/or to add a new issue
this form should POST its entries in a CGI script; this script updates the XML file on the server (using CVS access or HTTP PUT)

A better system would involve SOAP and XForms, but would require more time and the tool would be useful enough not to try the perfect solution first. Such a system would:

build an XForms directly from the XML file using XSLT
this XForms would either do directly an HTTP Put on the file
or use a SOAP 1.2 service to make the update on the file on our server (using SOAP would allow to re-use this service in many other places where it would be useful for)

SWD issues process looks reasonable; anybody can raise an issue, but the chair can reject them; that's a slightly optimistic optimization on the policy that only the chair can raise issues. The anti-pattern to avoid is where anybody can raise an issue, and the issues list becomes an unmanageable jumble of duplicates and incoherent issues. Also, raising an issue should be done with schedule concerns in mind. (hmm... pattern names... DenialOfService?)

TrackingIssues

Ontology

UI for ExIT

See Also