Re: Quality Control and that nasty A word (was: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal)

["James Kempf" <[e-mail]>]

Dave,

> A very serious problem with trying to assign responsibility to the Chair
> for quality, and the like, is that it _removes_ responsibility away from
> the rest of the working group.
>

This presumes that the motivations of the WG are to not produce a quality
spec. While this may sometimes be the case, I don't believe that it is
necessarily always the case, or rather, it should not always be the case.
The Chair and WG need to work as a team.

> The chair is responsible for facilitating a fair, timely, quality
> process.  The entire working group is responsible for actually achieving
> those things.
>
> This is not semantics.  It is a fundamental difference in views about
> the role of the Chair.
>

Clearly, quality requires more than just review at the end of the process.
Your pithy formulation of "review early, review often" is relevant here. The
WG needs to be responsible for quality, the WG chair needs to be responsible
to make sure that is carried through, and have the tools (relevance, what
have you) to carry it out.

As mentioned earlier, new proposed WG charters are starting to have quality
assurance plans. Suppose the IESG were to require that a charter contain a
QA plan before the charter is approved. Thus, the WG is taking
responsibility for quality by proposing the QA plan, the IESG is judging
whether the plan is likely to succeed (from their presumably broader
experience) by approving the charter or suggesting changes, and the chair
has the responsibility for carrying the QA plan out, with the authority
(relevance, etc.) granted to him/her by the WG through the charter.  To make
this work, the chair would need to have some tools available. The primary
tool would be an expert review board like SIRS, and a template of options
and standardized processes as to when reviews are typically carried out. The
WG could agree to make the review binding, or not, and pick from the
template what reviews they intended to have done and when. The IESG's
judgement about the plan would depend on the interest group wanting to form
the WG, the subject area, etc., (the IESG might also decide that they wanted
to review the documents themselves rather than have outside review, for
reasons of interest, possible effect on the Internet, etc.). Another QA tool
might be implementation (as in "running code"). The working group might
include at least one implementation of the protocol, to make sure that it is
cleanly designed from an implementation standpoint, or the IESG might
suggest that an implementation be done as part of the QA plan if they have
concerns. A final tool might be requiring more than one interoperable
implementation. I realize that, today, that is required only for DS, but
there might be cases where interoperability concerns are high at the PS
stage.

Would this satisfy your concerns?

                jak



_______________________________________________
mpowr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpowr