(hopefully) last message on WG process

Now that people have vented about the WG process, I'd like to declare
the subject of 'Working Group' process off-limits, unless you've
discussed the WG process with the WG chairs (myself and Dave Raggett)
and still feel that you haven't gotten satisfaction. It's a matter of
saving the mailing list for technical issues.

>   (a) the big changes to the spec do not seem to mirror the
>   conversation on the working group mailing list, or even to follow
>   the process described by Roy.

It has been acknowledged that this is annoying, and I hope to make
sure that people won't feel left out of the process again. Still,
we're going to take the latest 1.1 draft as baseline, and propose
changes to it, even if those proposals mean winding back to 1.1.

>    (b) issues that have been brought up repeatedly in the working
>    group are not resolved by the spec.

I'd like to hear (privately) about any issues that aren't the subject
of discussion of any of the subgroups.

>    (c) by ignoring things like Netscape's cookies, the working group
>    stands in danger of simply being bypassed by the market.

we're not ignoring it.

>    (d) it may be a mistake to introduce a large set of new
>    issues in the form of a monolithic I-D for the whole spec.

oh, it's certainly confusing, but I think 'mistake' is too strong.
Let's just agree that the current 1.1 draft is just a 'stake in the
ground' and that no one should attempt to code to it at the moment.

> (1) Like it or not, some of us cannot attend IETF or WWW meetings in
> person.  The mailing list MUST remain the document of record. 

Agreed, 100%

> (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.

However, for the most part I'm hoping we can handle this by
sub-groups. I'll keep a list of other issues, but I'll probably just
send it to the list from time to time. Send me (privately) any issues
that you think aren't handled by any of the subgroups (after the
minutes get out.)

> (3) Major additions and major changes to the spec MUST be discussed
> individually.  In some cases, a separate I-D might be the best approach
> (we can combine several I-Ds into a complete spec later on).  In other
> cases, simply describing the addition/change in a distinct email
> message to the mailing list should suffice.

I got in trouble before having too many I-Ds in the URI group, so I'm
wary of encouraging them. (Please ask before authoring a 'working
group' Internet Draft.)

> (4) To the extent that the spec involves both principles (such as
> caching or anti-byte-deluge, for example) and specific implementations
> of these principles, we SHOULD agree on the principles BEFORE
> fighting over the specifics.

people have trouble sometimes talking about principles in the absence
of implementation details. This sounds like a good idea but in
practice it's hard. Have some sympathy.

> (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 a nice idea, but we're often not up to it. If you have some
specific suggestions or questions on rationale that you think need to
be in the spec, please send them on as appropriate.

Received on Thursday, 7 December 1995 23:57:43 UTC