Issues and Actions (was: XHR2 Feedback As Tracker Issues)

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