====== 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):

  * [[https://github.com/w3c/csswg-drafts/issues|GitHub issues]] (preferred)
  * [[:spec|Wiki]] (fantasai notes from experience that if you track all issues in one page, it will eventually get [[:spec:css2.1|unweildy]], so consider a method for using sub-pages)
  * [[http://w3.org/Style/CSS/Tracker/|Tracker]] (historical)
  * [[http://www.w3.org/Bugs/Public/|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 [[http://dev.w3.org/csswg/css3-ui/|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 [[http://fantasai.inkedblade.net/weblog/2011/inside-csswg/process|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:

  - Link to the filed issue.
  - 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.
  - Request confirmation that the proposed resolution is OK.

Good examples (better examples would link to the issue):
  * http://lists.w3.org/Archives/Public/www-style/2012Feb/0269.html
  * http://lists.w3.org/Archives/Public/www-style/2010Oct/0829.html
  * http://lists.w3.org/Archives/Public/www-style/2010Sep/0066.html


Bad examples:
  * http://lists.w3.org/Archives/Public/www-style/2012Feb/0270.html
  * http://lists.w3.org/Archives/Public/www-style/2012Feb/0264.html

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 [[https://wiki.csswg.org/tools/doc|Disposition of Comments tool]] to manage and present the Disposition of Comments