An issue tracker should cater for the following things:
- Automatically track e-mails on the mailing list
Note the search service for W3C MailingLists supports "find all mail with issue-23 in the subject"
- Automatically keep an audit trail showing all changes to the issue
- Enable people to summarize arguments in a central place
- Ideally, with inline sample pages showing expected use
- Ideally, with a clear place to put use cases for any non-editorial feature or change request
- Have a way to categorise issues (e.g. "show me all open canvas issues")
- Make it clear what the current state of the issue is:
- raised/requested
- acknowledged
- open for discussion
- Closed, no objections
- Closed over objections
- Duplicate of issue XXX
Whether those are requirements or goals isn't really clear yet... and keep in mind there is an element of: those who do the work make the rules.
References
How about Bugzilla?
There's a Bugzilla setup for this; Product HTML WG and Component Web Apps 1.0 Review.
Products and Components
The Products and Components are tweakable to suit our needs. Web Apps 1.0 is no more; suggested replacements are:
- The DOM
- The semantics
- Browsing Contexts
- APIs
- The Language Syntax
Or we may want to make them task oriented; cf. eg. the original Web Apps 1.0 Review.
Status Keywords Currently in Bugzilla
The following table lists the Status Keywords already in Bugzilla which we may elect to reuse or amend.
changeDeclined |
The Working Group declined to implement the change which the reviewer requested. |
decided |
The WG has decided what to do about this item, but any changes needed have not been integrated into the status quo document. |
editorial |
An editorial issue - final wording may need WG approval, but WG does not need to discuss technical direction. |
erratum |
This issue has been identified as an erratum and a correction has either been issued or is in process. |
externalComments |
The reviewer is not participating in the Working Group. |
futureConsideration |
This issue may be considered for a future version of the specification. (Used when the feature in question is out of scope for the current version.) |
ICS |
Implementation Conformance Statement |
LC |
Last Call version of a specification |
needsAction |
The issue resolution depends on an Action Item realisation |
needsAgreement |
For XML Schema bugs which have been classified, but on which the WG has not yet reached technical ('phase-1') agreement. |
needsDrafting |
For XML Schema bugs on which the WG has reached technical ('phase-1') agreement; the next step is for the editors to draft wording for the spec along the technical lines agreed by the WG. |
needsPublication |
An editor has drafted proposed wording for the issue resolution, but it hasn't been published to the WG yet. |
needsReview |
There is a proposed resolution for the issue, but it hasn't been reviewed yet |
noFurtherAction |
For XML Schema bugs which have been classified as nongoals, or which have been overtaken by events, or abandoned; also for items which the WG believes should be dealt with by writing an explanation to the bug reporter but without a change to the spec. |
nonEditorialChange |
To implement the comment, the Working Group made a non-editorial change to the specification. |
noResponse |
The reviewer did not respond to the decision of the Working Group. |
notInDTD |
For the Markup Validator, labels issues that are not in the realm of validation, but should be considered for a conformance checker. |
proposalAccepted |
The Working Group has accepted the proposal of the reviewer. |
resolved |
For XML Schema bugs which have been resolved and the wording for which has been integrated by the editors into the status quo document. (This keyword may be omitted when the bug's Status field has the value "RESOLVED".) |
reviewerNotSatisfied |
The reviewer is not satisfied with the response of the Working Group. |
reviewerSatisfied |
The reviewer is satisfied with the response of the Working Group. |
SpecGL |
QA Specification Guidelines |
unclassified |
For XML Schema bugs which are awaiting classification by the WG |
Usability |
Usability of the tool, including accessibility of input and output, style, interface, simplicity of error messages... |