Subject: Issues list proposal
I have decided to use XML/XSL to manage the issue list for the TC. The format I’ll be using is derived from the current WS-Addressing issue list which itself is derived from another that has floated around in various forms from the W3C to OASIS to WS-I so it should strike some of you as familiar. I intend for the default XSL to render well in the browser so that HTML generation will be unnecessary.
The primary goal is to provide flexible sorting criteria and provide some searching capability. At its core each issue will have an auto incremented number of the form i000 with a title and description. In order to provide flexible sorting issues should have a specific target, my proposed list is: core, soap, wsdl, policy, schema and all. Issues should also be identified as either editorial or design. The issue originator and owner will also be logged.
Ignoring the XML serialization below are the proposed statuses that will be tracked for issues.
Open Unassigned : After the TC has agreed to log an issue. Minute of the conf-call/F2F should reflect this decision
Open Active : After the issue has an assigned owner to shepherd discussion
Editor Pending : TC has agreed upon a resolution, ready for editor queue. Minutes of the conf-call/F2F should reflect this decision.
Editor Done : Editors have acted upon the issues
Resolved : Reviewed by the TC (some light weight process, for example, one or more members volunteer and review the changes)
Closed : Voted by the TC as part of the CD voting
Additionally there is one other status for “dropped”.
Other fields of interest are justification, notes, relissue, proposal and resolution. Justification describes in additional detail to the description itself why this is an issue. Notes can contain a subset of html and will reference to email discussion threads in the archives to track the discussion of the issue. Proposal and resolution are fairly self explanatory, they will log the appropriate date and email post in the archive for each. There can be n proposals and of course only one resolution. Relissue will be used to tag related issues for potential sorting and tracking purposes.
As to search I’ll follow the example of the WS-Addressing WG and attempt to use the OASIS mail archive search capabilities. This will be greatly facilitated by following some conventions when discussing mail on the list. The most important of which is that when discussing an issue please use the issue number in the subject field. We should also follow a convention for raising new issues on the list to facilitate addressing them on our calls. Again taking a cue from the WS-Addressing WG please use a subject header in the form "NEW ISSUE: title". Issue proposals must include the following information:
Title - A short descriptive name for the issue
Description - A longer and complete description of the issue, state in terms of the documents
Justification - Why is this an issue? E.g., state an architectural concern, demonstrate an interop problem, explain a use case that isn't met
Target - What deliverable the issue is against (core | soap | wsdl | policy | schema | all)
Proposal - A reasonably complete proposal for how the issue should be addressed.
I’ll have schema and xsl posted by early next week to the TC document store.