- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 17 Jun 2008 00:21:38 -0400
- To: public-webapps <public-webapps@w3.org>
- Cc: Arthur Barstow <art.barstow@nokia.com>
Hi, Art- Arthur Barstow wrote (on 6/16/08 8:18 PM): > > The general model we used in the WAF WG is to document most "issues" in > the spec. We only moved an issue to Tracker when there were clear > differences of opinion i.e. no consensus (and we wanted to document > additional pointers, etc. regarding the issue). > > If we follow that model for this case, we would debate/discuss a > specific topic before it is officially moved to an issue in Tracker. > > I realize other WGs follow a model where the threshold for adding an > issue to Tracker is a bit more loose. If others think this type of model > is more appropriate, I'd be interested in hearing the rationale. In general, I think using the tracker can be more effective at dealing with issues than merely using email or notations in the spec, for a number of reasons: 1) emails to the list that are relevant to the issue will be picked up automatically, as long as the issue number is raised; 2) it provides greater transparency into how the issue is resolved; 3) any WG member can raise an issue, so it decreases the load on the editor in terms of collecting issues; 4) it ensures that all issues are dealt with, and aren't swept under the rug or forgotten; 5) it breaks down complicated matters into atomic issues, while emails often ramble and spawn new threads; 6) since issue are associated with particular "products" (deliverables), it is easier to follow than email threads which may touch on multiple deliverables; 7) if substantive new evidence or opinions come forward after an issue is resolved, it is easier to find how that fits into the technical details and discussion of the original issue; 8) if an old issue is raised later, the group can point to a single place to educate the new inquiry, rather than merely pointing them to the email archives or saying only, "we discussed this before"... hopefully, this will lead to fewer permathreads; 9) if an issue is contentious and needs to be defended during transition, this will make creating a disposition on comments easier; 10) this is a system that is familiar to most implementors already; 11) the agenda for a meeting can be generated easily by stepping through the issues in the tracker. A downside of using the tracker is that it works best for smaller issues that can be summarized fairly easily... major architectural issues are not well represented in this format. Also, if an issue crosses different deliverables, it's not as easily categorized (though you could easily create products that cover a specific set of issues, like "All" does more generally). There may be other drawbacks; can anyone share any? Are there advantages to other approaches, such as the one Art mentioned? It's no harder to raise an issue, or to respond to it, than it is to write an email. Given that, is there a reason not to use the Tracker more liberally? Note that there is a difference between issues and actions. I'm sure Art knows the distinction, but for any others: * Issues are not actionable items, but topics that need discussion and resolution; an issue may spawn one or more actions, or may not spawn any; issues may still around for a long time as things to consider; * Actions are specific tasks that need to be accomplished by a given person within a certain timeframe; they may come from formal issues, or they may simply arise during a discussion; they are meant to be resolved quickly. Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
Received on Tuesday, 17 June 2008 04:30:50 UTC