This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| spec:issues [2014/07/21 11:15] – [1. Pick an Issue Tracker] fantasai | spec:issues [2014/12/09 15:48] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Best Practices for Issue Resolution ====== | ====== Best Practices for Issue Resolution ====== | ||
| - | So you're a spec editor now. Congrats! You my think you will be spending your days drafting beautifully-crafted spec text to describe the newest features you've just dreamed up, but in fact, you will //mostly // be living in a mailing list addressing all the bugs in what you (or your predecessor) have already written. | + | So you're a spec editor now. Congrats! You may think you will be spending your days drafting beautifully-crafted spec text to describe the newest features you've just dreamed up, but in fact, you will //mostly // be living in a mailing list addressing all the bugs in what you (or your predecessor) have already written. |
| Fear not! There is a (temporary) end to the issues (if you are diligent enough to hit Inbox Zero). Note: This is sometimes called Last Call. It will flood you with more issues. | Fear not! There is a (temporary) end to the issues (if you are diligent enough to hit Inbox Zero). Note: This is sometimes called Last Call. It will flood you with more issues. | ||
| Line 31: | Line 31: | ||
| Record your favored issue-tracker’s URL into the spec's header. You can change your mind later, but in that case don't forget to update that URL. | Record your favored issue-tracker’s URL into the spec's header. You can change your mind later, but in that case don't forget to update that URL. | ||
| - | ===== 2. Find your Issues ===== | + | ===== 2. Find your Issues |
| Aside from the ones already in your tracker, there are more in the mailing list, usually tagged with your spec's shortname in brackets. | Aside from the ones already in your tracker, there are more in the mailing list, usually tagged with your spec's shortname in brackets. | ||
| + | Make sure you're tracking all of them. Or at least, all the open ones. | ||
| ===== 3. Address (and communicate!) your Issues ===== | ===== 3. Address (and communicate!) your Issues ===== | ||
| - | As the spec editor, you are charged with the responsibility of representing the CSSWG in the resolution of your issues. | + | As the spec editor, you are charged with the responsibility of **representing the CSSWG** in the resolution of your issues. |
| Part of this responsibility is the technical and editorial task of solving the issue consistent with CSS’s design principles and making edits accordingly. | Part of this responsibility is the technical and editorial task of solving the issue consistent with CSS’s design principles and making edits accordingly. | ||
| Line 44: | Line 45: | ||
| * [[http:// | * [[http:// | ||
| - | But another part of it is also communicating the issue and its resolution | + | But another part of it is also creating a resolution |
| ==== Choose Your Authority ==== | ==== Choose Your Authority ==== | ||
| Line 64: | Line 65: | ||
| * Issues that could break compatibility with CSS2.1 or existing Web content | * Issues that could break compatibility with CSS2.1 or existing Web content | ||
| * Anything you're unsure of | * Anything you're unsure of | ||
| + | |||
| + | Because the WG is a mix of experts and implementer reps, raising issues to the WG gives you access to more expertise when resolving the issue, and also communicates the resolved changes back to the implementation teams who will be impacted by them. WG meetings and agendas are also broadcasted to a wider audience, so even implementers not in the CSSWG will be more likely to follow an issue raised to the WG. | ||
| == Resolve with your peers == | == Resolve with your peers == | ||
| Line 75: | Line 78: | ||
| ==== Raising Issues to the WG ==== | ==== Raising Issues to the WG ==== | ||
| - | Sometimes its appropriate to raise an issue to the WG discussion. | + | You can look at the CSSWG as a bureacratic approval committee that you must appease. Or, you can look at it as a group of really smart and knowledgeable people who care about making your spec better but whose attention you need to cultivate because we're all way too overloaded to read every thread on www-style. Personally, I start with the assumption that the CSSWG’s review would be very useful on everything, but attention is a limited resource so my job is to |
| - Filter out issues they don't need to care about because they' | - Filter out issues they don't need to care about because they' | ||
| - Do a really good job of summarizing the issue so as many people as possible can really understand the problem and the proposed solutions (if any) and help resolve the issue better than I could by myself. | - Do a really good job of summarizing the issue so as many people as possible can really understand the problem and the proposed solutions (if any) and help resolve the issue better than I could by myself. | ||
| Line 98: | Line 101: | ||
| Despite its much-maligned downsides, this process has some benefits: | Despite its much-maligned downsides, this process has some benefits: | ||
| - | * It forces you to update the CSSWG, at a high level, on what's going on with your spec. This is good, because it pulls in the attention of some very busy experts, who can suggest design improvements, | + | * It forces you to update the CSSWG, at a high level, on what's going on with your spec. This is good, because it pulls in the attention of some very busy experts, who can suggest design improvements, |
| * It helps you to engage with people who cannot keep up with your lightning speed of progress, such as the i18nWG, the authoring community, implementors who are currently paying attention to their other projects, and members of the CSSWG who aren't following your every brilliant typo fix. Slackers. | * It helps you to engage with people who cannot keep up with your lightning speed of progress, such as the i18nWG, the authoring community, implementors who are currently paying attention to their other projects, and members of the CSSWG who aren't following your every brilliant typo fix. Slackers. | ||
| * It makes sure you fixed all those markup errors you accidentally introduced since the last publication. (Oops.) | * It makes sure you fixed all those markup errors you accidentally introduced since the last publication. (Oops.) | ||
| * Gives you an opportunity to distill your progress and present it (via the CSSWG Blog and other news outlets) as exciting updates for which the authoring community can provide feedback. | * Gives you an opportunity to distill your progress and present it (via the CSSWG Blog and other news outlets) as exciting updates for which the authoring community can provide feedback. | ||
| - | * It helps with spec archaeology by providing easily-searchable | + | * It helps with spec archaeology by providing easily-findable |
| + | Publish early, publish often. | ||