This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
spec:issue-tracking [2011/10/30 10:49] – created with some consensus from the CSSWG f2f Tantek | spec:issue-tracking [2018/04/25 09:41] (current) – [Where to Track Issues] chrisl | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Issue Tracking ====== | + | ====== Issue Tracking |
- | Issues are tracked in the CSS Working Group as follows: | + | |
- | * Editor' | + | ===== Where to Track Issues |
- | * If all issues are tracked in the draft itself, this may just be a note saying as such. | + | |
- | * Each CSS spec tracks issue in one of the four following ways per the preference of the spec's editor: | + | |
- | - This wiki, e.g. see the individual spec pages linked from the [[../ | + | |
- | - The W3C Issue Tracker | + | |
- | - Bugzilla | + | |
- | - Inline in the spec itself | + | |
- | If you're editing a spec, please | + | Issues are tracked in the CSS Working Group by the spec editors using one of the following mechanisms (per the editors' |
+ | |||
+ | * [[https:// | ||
+ | * [[:spec|Wiki]] (fantasai notes from experience that if you track all issues in one page, it will eventually get [[: | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * Inline in the spec itself (please | ||
+ | |||
+ | Each spec has a link in its header to where issues are tracked for the draft (e.g. see " | ||
If you have a better mechanism you'd like to use, please first propose it to the working group. | If you have a better mechanism you'd like to use, please first propose it to the working group. | ||
+ | ===== Editor' | ||
+ | |||
+ | It is part of an editor' | ||
+ | |||
+ | (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:// | ||
+ | |||
+ | ===== 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: | ||
+ | | ||
+ | * If you are accepting, exactly what edits were made. (If you haven' | ||
+ | * 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:// | ||
+ | * http:// | ||
+ | * http:// | ||
+ | |||
+ | |||
+ | Bad examples: | ||
+ | * http:// | ||
+ | * http:// | ||
+ | |||
+ | 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' | ||
+ | |||
+ | There is a [[https:// | ||