The Web interface is pretty straighforward and probably best demonstrated by example. This page is just a summary of the important features.

URI design

While URIs are opaque, it doesn't hurt to make them understandable just in case. The entire Tracker system runs from a single PHP file and uses Apache redirects to form a virtual URI space. Assuming that BASE is the place where Tracker is installed (eg. “http://www.w3.org/2004/CDF/Group/track”) then the virtual mapping is defined as below.

TRACK/issues/

Gives the list of all issues.

TRACK/issues/open

Gives the list of all open issues.

TRACK/issues/33

Gives information on ISSUE-33.

TRACK/issues/33/edit

Allows ISSUE-33 to be edited (Note that it doesn't actually edit the issue, just displays an editing form - I'm not getting my GETs and POSTs mixed up :)

The same design applies to actions.

TRACK/actions/84

Gives information on ACTION-84.

TRACK/users/

Gives information on all users.

Raising an issue

All Issues MUST be raised using the Web interface. It's the “Create/Raise Issue” link in the sidebar. It gathers the required information, inserts the new issue into the database, send an email about the issue to the Working Group and then just kicks back and waits for the discussion.

Closing an issue

For now, issues are closed via the Web interface by using the “edit this issue” link in the sidebar on the issue page. Be sure to include notes on the resolution.

iCalendar subscription

The summary page for each user (found via the “Users” link on the sidebar) has a link to an iCalendar subscription. This provides calendar software with the details of the user's open ACTIONS (title and due date).

Your calendar software will, in most cases, need to be able to retrieve protected URLs (ie. it will need to authenticate into W3C Member space in the same way as your browser). Most good calendar programs do this. It also shouldn't be a problem for Members that have set up IP-range authentication.