- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 07 Dec 95 16:47:14 PST
- To: "Daniel W. Connolly" <connolly@beach.w3.org>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>(2) Someone in the "working group management" MUST maintain a list of
>unresolved issues, preferrably as Web page so that people can check the
>current status.
This is a great idea, but I've tried to do it, and found it to be
exceedingly difficult. I expect some suitably easy-to-use issue
tracking tools to hit the web any time now, what with all the
collaboration experiments and Java applets wizzing around.
I'm not looking for any fancy tracking tools. I'm looking for a list
that is kept reasonably up-to-date by a human.
It doesn't even have to be in HTML format.
I think this is part of the task of the working group chair(s). It
sets the agenda for discussion, and (as I wrote in my original message)
someone has to make decisions about what goes on and comes off.
If anyone volunteered to maintain this list, they would effectively
be running the working group.
>(5) Proposed additions and changes to the spec MUST be accompanied by a
>written rationale, and SHOULD be accompanied by at least an attempt to
>analyze the proposal with respect to possible alternatives. I would
>like to see brief summaries of these rationales and analyses included
>in the spec itself, since this would aid implementors in understanding
>the spec, and would probably avoid some future arguments.
This is another good idea. Again, I've found that it's a LOT of work.
I think you'd need another editor to take on the work of doing
a rationale. Any volunteers?
Nonsense (with all due respect!). Anyone who writes a specification
should be expected to justify that specification. If the rationale
doesn't appear in the spec per se, it will be dragged out of the
spec writer on the mailing list (or perhaps at a meeting, but then
the whole issue will be re-opened on the mailing list by those of
us not lucky enough to attend).
I'm not arguing for a separate rationale document, I'm arguing that
all non-obvious parts of the spec should include some rationale
inline. Not a PhD dissertation; just something explicit.
-Jeff
Received on Thursday, 7 December 1995 16:57:14 UTC