Latency

[Keith Moore]

> Take the (proposed) lemonade WG that has just recently been discussed.
> I'm not part of that effort, but from what I saw of its intended
> charter, it looks as if they have already pretty much determined just
> what problems they're intending to handle, and even in some cases the
> general direction of the solution (if anything the charter makes it
> appear that some of the work is essentially done, and just needs
> approving).

Actually I had the opposite impression.  But perhaps that's due more to
a tendency to use vague and impressive-sounding language in charters
than an actual lack of understanding among the group's proponents as to
the problem to be solved.  Still, that kind of wording in charters may
confuse newcomers to the group.

> Yet the first milestone on their list is to write a requirements doc.
> That seems (in that particular case) like a colossal waste of time to
> me.

I see no reason why a problem definition (please stop calling them
requirements docs! :) shouldn't elaborate on the charter.  But it should
also be < 20 pages (ideally < 10) and it should be completed and ready
for review in six weeks.

For instance in the case of lemonade it would be useful to list specific
areas where IMAP is known to have problems and for which it appears to
need refinement/profiling/uniformity/extensions.

> In most cases, there should be enough of the requirements in the
> charter - that's supposed to set out what the group is to do.  If
> they have no idea, they can't really write a reasonable charter.

"They" may apply to IESG as well as to working groups.  But I don't
think that the charter should try to specify the level of detail of a
problem definition.  I think about it this way - the charter tries to
summarize the scope of the group in 1 page; the problem definition
should try to bound the problem space in some detail, identify unsolved
sub-problems and potential conflicts early, and outline the scope of the
effort in 10-20 pages.

The problem definition may also be useful in identifying conflicts that
weren't anticipated by the charter, and this in turn may be useful in
refining the charter (and in particular the deliverables and schedule)

> ps: this WG (or mailing list or whatever it is) is another example of
> a WG that has been created just to write a requirements doc (or
> something closely enough related to that to be almost
> indistinguishable). 

Actually it's been created to come up with a problem statement.
while that may mean the same thing as "requirements" to you, note that
we're specifically being asked *not* to outline solutions at this time. 
And people writing requirements are far too often tempted to do just
that.

Keith