RE: COACH draft now available

[<john.loughney@nokia.com>]

Hi Harald,

> Overall comment: At first glance, it appears to be a move towards "high 
> ceremony" standard-making. But the limited size and pragmatic guidelines 
> might help us get away with it - after all, one should be able to write the 
> first draft of a 5-page document in an afternoon!

The intention is not to make it 'high-ceremony' but more deterministic
with more explicit steps.  The IETF is a highly informal organization,
and informal organizations do suffer from scaling and expansion
problems.
 
> It also appears to be somewhat misleading in its title - I'd see the making 
> of quality plans as just one tool in the toolbox of "going 
> for quality".

I think that that is a reasonable criticism - this is just one aspect
of the quality mosiac.

> Some comments while I'm reading:
> 
> - It adds new things to the WG charter: Individuals who have signed up to 
> do work. This may be a good thing to do, but it seems odd to have this 
> change in procedures for the charter buried inside the description of the 
> quality plan. Also, it turns changes of personnel into charter revisions - which 
> increases overhead.
>
> Might it be better to split this section into "charter" (as today) and 
> "resource plan" (not only editors, but also committed reviewers)?

That might be a reasonable compromise.  One additional benefit is
this may provide some folks justification for participation to
their non-IETF managers.

> - 2.3 introduces the review plan, which starts off with the challenge 
> assessment review, whose purpose is to produce the challenge assessment 
> section of this document. This seems to be a bit circular - are you 
> assuming a model where the document starts out nearly empty, and then gets 
> filled through review? if so, version control of the quality plan should be 
> mentioned..... including the issue of who gets to approve it....

I need to come back to this point.

> - the Last Call should be considered part of the review plan. I'd also 
> expect the usefulness of issue trackers to grow larger near the end of a 
> cycle; after all, "this approach is hopeless" (a natural early issue) is a 
> hard issue to track, while "the convergence time needs to be specified as 
> 30 msecs, not 50" is a very easy one to track.

Agreed, we can look at how to incorporate this.

> - 3. post mortem. As we've observed before, the AD tends to "marry" the 
> group's result in the end process. It might be better to have someone else 
> do the quality asessment - after all, if the quality is lousy, but still 
> gets out, we want to learn from that too: what were the circumstances that 
> forced us to live with it?

Agreed.

John