[Icar] Re: [Solutions] Summary of Discussion on Reforming IETF Quality Control Process

Alex Rousskov <rousskov@measurement-factory.com> Mon, 12 January 2004 19:30 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12536 for <icar-archive@odin.ietf.org>; Mon, 12 Jan 2004 14:30:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag7lM-0001OB-1j for icar-archive@odin.ietf.org; Mon, 12 Jan 2004 14:30:12 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CJUCCv005338 for icar-archive@odin.ietf.org; Mon, 12 Jan 2004 14:30:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag7lK-0001O0-CQ for icar-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 14:30:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12514 for <icar-web-archive@ietf.org>; Mon, 12 Jan 2004 14:30:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag7lH-0002Y1-00 for icar-web-archive@ietf.org; Mon, 12 Jan 2004 14:30:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag7jd-0002Uq-00 for icar-web-archive@ietf.org; Mon, 12 Jan 2004 14:28:27 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag7iF-0002Pf-00 for icar-web-archive@ietf.org; Mon, 12 Jan 2004 14:26:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag7iG-0001KA-Rp; Mon, 12 Jan 2004 14:27:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag7hW-0001JE-Q7 for icar@optimus.ietf.org; Mon, 12 Jan 2004 14:26:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12349 for <icar@ietf.org>; Mon, 12 Jan 2004 14:26:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag7hU-0002MY-00 for icar@ietf.org; Mon, 12 Jan 2004 14:26:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag7fd-0002Ho-00 for icar@ietf.org; Mon, 12 Jan 2004 14:24:18 -0500
Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1Ag7ef-0002Dq-00 for icar@ietf.org; Mon, 12 Jan 2004 14:23:18 -0500
Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i0CJN5k3023074; Mon, 12 Jan 2004 12:23:06 -0700 (MST) (envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i0CJN52I023073; Mon, 12 Jan 2004 12:23:05 -0700 (MST) (envelope-from rousskov)
Date: Mon, 12 Jan 2004 12:23:05 -0700 (MST)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: James Kempf <kempf@docomolabs-usa.com>
cc: solutions@alvestrand.no, icar@ietf.org
In-Reply-To: <029201c3d712$48293870$606015ac@dclkempt40>
Message-ID: <Pine.BSF.4.58.0401121110540.15125@measurement-factory.com>
References: <029201c3d712$48293870$606015ac@dclkempt40>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Icar] Re: [Solutions] Summary of Discussion on Reforming IETF Quality Control Process
Sender: icar-admin@ietf.org
Errors-To: icar-admin@ietf.org
X-BeenThere: icar@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/icar>, <mailto:icar-request@ietf.org?subject=unsubscribe>
List-Id: Improved Cross-Area Review <icar.ietf.org>
List-Post: <mailto:icar@ietf.org>
List-Help: <mailto:icar-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/icar>, <mailto:icar-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60

On Fri, 9 Jan 2004, James Kempf wrote:

> I've written a draft summarizing the discussions on reforming the
> IETF quality control process that started on mpowr in December and
> wandered to solutions in January. It's here:
>
> http://www.geocities.com/kempf42/draft-list-quality-control-00.txt

James,

	Thank you for writing the draft. Here is my high-level
feedback. I assume we are not interested in low-level polishing at
this time.

1. "The ultimate responsibility for ensuring the quality
   of technical work done in the IETF lies with the Working Group..."

   I suspect you meant:

   "The ultimate responsibility for producing quality technical work
    in the IETF lies with the Working Group..."

   It is correct that WG/authors are responsible for producing quality
   output. It is wrong to imply that WG can ensure that. We need
   outside controls to ensure quality and your wording does not
   reflect that intent.

   Also, how does the above statement is affected by the fact that
   IESG can make WG-unapproved changes to WG documents? Do such
   changes make IESG responsible? Would it be more accurate to
   say that WG is responsible only up to a point where IESG takes
   control and does its conflict resolution thing?

2. "The ultimate responsibility for the quality of editorial content
   of the document describing the work lies with the authors and
   editors of the document."

   Sounds nice, but how does this reconcile with #1 above? The Author
   cannot overrule WG consensus. Are you implying that the author
   should resign if she disagrees with the WG consensus regarding
   her document?

3. "The IESG is responsible for deciding which Working Groups will
   require full IESG review on their documents"

   Wrong granularity, IMO. IESG decision should be made on document
   basis not WG basis, in general. That does not prevent IESG from
   reviewing every document of a given WG, of course, but it does
   not require that either.

4. "For documents that require IESG review or IETF management actions
   involving quality issues, the Area Director is responsible for
   ensuring that ...
   the [IESG] results are communicated to the Working Group, in as
   prompt a fashion as possible."

   A good review mechanism should not require manual involvement to
   communicate IESG (or any reviewer) actions on a document. We should
   avoid problems that manual forwarding of decisions always causes.

5. "Members of the board (called "Reviewers") may be
    subject experts with deep but fairly narrow expertise in one
    particular area, but more often they will have broad experience in
    a variety of areas involving Internet technology."

   I do not understand why deep expertise is worse than broad one.
   Why are you making this distinction? Is this sentence important?

6. Quality Review Board membership.

   I believe that any Board membership approach based on formal
   AD approval and/or popularity contest (IETF voting) is inferior
   to an "open pool of reviewers" approach. I hate to see IETF
   using such rigid mechanisms of "traditional" SDOs in a what is
   supposed to be an open volunteer organization.

   More specifically, I believe that the review pool/board should
   be open to anybody who volunteers and plays by the rules.

   There has to be a mechanism that identifies reviewers
   currently "trusted" by IESG, of course. Such mechanism
   will ensure consistency of reviews and IESG actions should the
   latter be necessary. Designing this mechanism is not trivial,
   but we can succeed if we focus on that rather than "membership
   rules".

   There should be no automatic inclusion or exclusion from the
   pool/board. We should not drag senior IETFers into the pool
   just because we can identify them by their IESG memberships
   or RFC counts. If they want to help, they will volunteer.
   We should not exclude idle reviewers from the pool because
   they did nothing wrong per se (rejecting review opportunities
   should not be counted _against_ anybody; it should be counted
   for solicitors to see and interpret).


7. "A determination of whether a full IESG review is necessary should
   be included in the Working Group Charter in order that the review
   process can proceed predictably"

   I do not understand the justification of this heavy requirement.
   Why is it important to know a priori that all WG documents will
   be fully reviewed by IESG? Will it make the WG work harder? Will
   it make the Chair look more important? Will it make other WG
   feel less important? What is the value to be gained from knowing
   that all WG documents will be reviewed by IESG, especially since
   IESG can review any document without a prior warning? This design
   also assumes that we are good at predicting what needs a
   full review even before the work has started.

   What problem does this WG flag solve??

8. Review Process

   The AD should not remove reviewers from the proposed list. The
   only thing an AD can do is to add reviewers if he thinks that
   proposed list does not provide enough trusted coverage.

   The review request should be sent to all reviewers accepting
   such requests, not just the ones on the AD-approved list.

   The whole design should make unknown but good reviewers known.
   This feature is essential for attracting always new/fresh
   reviewers and ensuring smooth scale.

   Full IESG review should not be a special case as far as
   notification and "handling" is concerned.

   All reviews must be archived and cross-referenced with
   documents and reviewers.


9. Disposition of Review Results

   The reviewers should be responsible for classifying their
   own comments and entering them into the review database.
   The Chair should not be involved at that stage. Again, we should
   not create a forwarding dependency/role when none is required.

   The above suggestion does create some extra work for some
   reviewers, but it is "good" work. It keeps reviews cleaner and
   more constructive. It also avoids problems with Chairs missing
   a comment or mis-classifying it. Finally, it actually saves
   reviewers time in the long run because they can check how their
   comments were addressed without mapping their comments with
   Chair's rendering of their comments.

   The review database/interface should be provided on IETF web
   site for everybody to use. The "issues page" is generated by
   IETF software, not Chairs. This provides everybody with a
   familiar interface and, again, solves "forwarding" problems
   like a forgotten, misrepresented, or even
   changed-after-final-reviewer-check issue on a Chair-controlled
   web page.

   IMO, we need an IETF-wide review management system to facilitate
   key review-related improvements we want.

Thank you,

Alex.

_______________________________________________
Icar mailing list
Icar@ietf.org
https://www1.ietf.org/mailman/listinfo/icar