Issue Tracking and Resolution

Where to Track Issues

Issues are tracked in the CSS Working Group by the spec editors using one of the following mechanisms (per the editors' preference):

  • GitHub issues (preferred)
  • Wiki (fantasai notes from experience that if you track all issues in one page, it will eventually get unweildy, so consider a method for using sub-pages)
  • Tracker (historical)
  • Bugzilla (historical)
  • Inline in the spec itself (please avoid for non-trivial issues)

Each spec has a link in its header to where issues are tracked for the draft (e.g. see “Issues List:” in header of CSS3-UI editor's draft). If all issues are tracked in the draft itself, this points to the editor's draft.

If you have a better mechanism you'd like to use, please first propose it to the working group.

Editor's Decision vs. CSSWG Resolution

It is part of an editor's responsibility to bring issues to the WG for discussion when appropriate. This is not an escalating conflict-resolution mechanism. This is about the editor's job being to filter out and deal with obvious issue resolutions, and to coherently present the remaining issues to the WG for discussion and resolution.

(The CSSWG editor role is that of an intelligent secretary: you can freely draft things in the early stages, call the shots on the straightforward and obvious changes when you know the boss would agree and won't need to review personally—but you're not in charge here.)

The level of WG oversight on a spec depends on its maturity: the closer a spec is to REC, the less leeway the editor has for making unilateral decisions.

Responding to Last Call Comments

(This is actually good practice for all issues, not just Last Call. But it's especially important for Last Call.)

First, file the issue. Then, in your response include:

  1. Link to the filed issue.
  2. Your response:
    • Whether you are accepting or rejecting the comments.
    • If you are accepting, exactly what edits were made. (If you haven't made the edits yet, make the edits first, then respond.)
    • If you are rejecting, the rationale for rejecting.
  3. Request confirmation that the proposed resolution is OK.

Good examples (better examples would link to the issue):

Bad examples:

In some cases, the issue is more complicated and some back and forth is required. But at some point, there should be a final response that represents the editors' (or WG's) position, requests confirmation that it's acceptable, and gives the commenter enough information to make an informed decision about whether that position is acceptable.

There is a Disposition of Comments tool to manage and present the Disposition of Comments

 
spec/issue-tracking.txt · Last modified: 2018/04/25 09:41 by chrisl
Recent changes RSS feed Valid XHTML 1.0 Valid CSS Driven by DokuWiki