[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: COACH draft now available
> 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
> 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?