[dir-coord] reminder about early reviews

Jari Arkko <jari.arkko@piuha.net> Wed, 19 November 2014 00:09 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: dir-coord@ietfa.amsl.com
Delivered-To: dir-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E60C1A87CC; Tue, 18 Nov 2014 16:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.206
X-Spam-Level:
X-Spam-Status: No, score=0.206 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27Ou41sXLMyJ; Tue, 18 Nov 2014 16:09:44 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 84AE41A87CA; Tue, 18 Nov 2014 16:09:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4ECF82CED0; Wed, 19 Nov 2014 02:09:08 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwqxr8gRqCLd; Wed, 19 Nov 2014 02:09:07 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 48B922CC4D; Wed, 19 Nov 2014 02:09:07 +0200 (EET) (envelope-from jari.arkko@piuha.net)
From: Jari Arkko <jari.arkko@piuha.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 19 Nov 2014 01:09:07 +0100
Message-Id: <A01BAB92-4583-4F7D-9A2E-65901FB703E9@piuha.net>
To: IETF WG Chairs <wgchairs@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dir-coord/_Y3qKQVaxNxyrR0oxCrM4G_DBxc
Cc: dir-coord@ietf.org
Subject: [dir-coord] reminder about early reviews
X-BeenThere: dir-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is an e-mail alias for the organisers of IETF directorates." <dir-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dir-coord>, <mailto:dir-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dir-coord/>
List-Post: <mailto:dir-coord@ietf.org>
List-Help: <mailto:dir-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dir-coord>, <mailto:dir-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Nov 2014 00:09:49 -0000

Thanks for your hard work last week.

I talked to one of my review teams, and found out that we have 
not recently received any early review requests. I wanted to
remind you that in cases where an early Gen-ART, etc review
would be useful, you can request them by sending mail to the
specific review team secretary or to the common review team
list at dir-coord@ietf.org.

The purpose of these early reviews is to move more of the IETF
end-of-the-process work under the WG phase and under your
management, and to get feedback slightly earlier than you would
otherwise get it. Please find below an earlier e-mail describing
the arrangement:

> Internet Drafts sent for approval as RFCs are reviewed by individuals during the IETF Last Call, the Area Directors, IANA, as well as a number of volunteers from various directorates and review teams. The reviews from these teams has gained a significant role in ensuring that the IETF produces high-quality, understandable and implementable RFCs.
> 
> Yet, as discussed in http://www.ietf.org/blog/2013/05/balancing-the-process/ we have a general problem that quite a lot of the work around IETF documents happens at the end of the process. In particular, a number of the reviews during IETF last call point out issues that end up being raised by the IESG as comments. It is of course good that issues are caught, but raising them earlier would be better. And it would be better if the working groups - the intended focus point of work on a topic - would get to handle them, as opposed to raising these issues with the IESG. The IESG discussed these issues in its May 2013 retreat, and decided to experiment with three actions designed to move more work to the responsibility of the working groups:
> 
> (1) Perform some reviews that are now happening at IETF Last Call a bit earlier. This will put the working group in a bigger role in resolving cross-area and general issues.
> 
> (2) Invite document shepherds on IESG telechats when there's a document that is likely to require discussion. This will make it possible for the document shepherd to me directly be 
> 
> (3) When a document has a number of issues, hand over the process back to the working group, as opposed to the IESG tracking the issues. Among other things, this will ensure that changes are discussed in an open working group list and agreed through consensus.
> 
> Some of you have seen (2) and (3) happen, more will come. For (1), building quality and cross-area review to the process earlier is of course a big effort. We plan to launch an experiment to make a small change to current directorate review procedures to learn if we can move reviews a little bit earlier. If successful, this experiment will enable working groups to deal with issues before IETF Last Call and IESG review and empower the working groups to be in charge of the documents throughout their life cycle. We are also hoping that document quality will improve and number of issues discussed in the IESG will be lower.
> 
> While the number of reviews as such is not changed, some additional effort and care will however be required from the reviewers, directorate coordinators/secretaries, the working group chairs, and other participants. The experiment will show us whether this effort is reasonable and if there are any unexpected effects. The experiment is performed on a voluntary basis by each directorate. As early review requests come in, the directorates can throttle workload by either processing the requests or reverting to the existing procedures. Initially, the Gen-ART, Security Directorate, and Applications Area Directorate are included in this effort. Other directorates may be added later. The experiment will be reviewed after six months.
> 
> Care must be taken to avoid a number of possible drawbacks. There may be problematic documents that would require much re-review and effort. Similarly, working groups often perform a number of working group last calls on a document, and it would be undesirable to engage the reviewer before the document was really ready to be sent forward. And when reviewers send comments, it is important that the group listens to the comments in the right way, like you would for a review from a security expert or a general networking expert. E-mail practices around sending and responding to comments have to be carefully managed, as the outside reviewers are typically not list members.
> 
> For the working group chairs, you can request a review by sending mail to dir-coord@ietf.org, indicating the name of the document. You can ask for a review as soon as a working group last call has ended successfully and the document edits are done. Initially, it would make sense to ask for reviews on documents that you feel are likely the most stable ones. To avoid congesting the reviewer resources, ask for this service only for some documents, not as a wholesale service on every document you submit for publication. 
> 
> You can ask for the review in parallel with ongoing AD reviews, filling out the shepherd questionnaire, etc. The hope is that reviews can come in in the same time frame as other tasks in this stage, and that you can take the comments into account and revise the document before finally sending it out for IETF Last Call. Reviews will be sent to you and potentially the working group mailing list. You may need to forward comments and/or approve new posters to the list. Discussion on the mailing list is encouraged, but please try to ensure that the reviewer is kept on the Cc line, as he or she may not be on the list itself. Treat the reviews with respect and keep it in mind that outside experts may have opinions that need to be taken into account, even if the working group had not considered those aspects before. Mediate and monitor the discussion actively. Try to keep the reviewer out of e-mail storms and work out solutions separately and then engage the reviewer again.
> 
> For the directorate coordinators/secretaries, please monitor the dir-coord@ietf.list. If there is a request for a review, dispatch the task to a reviewer. Managing overload is your task. Please acknowledge requests and whether you can accommodate them. Directorates that today review documents twice, at IETF Last Call and then before entering the IESG telechat should continue this practice by doing the early review and then the IESG telechat review. Existing practices such as retaining the same reviewer for checking the same version is useful. Your review tools and practices may need adjustment to accommodate reviews happening at different times.
> 
> For the reviewers, take into account the context. Post your reviews to the working group chairs, authors, and Cc the working group mailing list if necessary. If your review team uses a template for these e-mails, some changes may be necessary in the template for the early review. Some of those changes have been discussed, e.g., in the Gen-ART list.


Jari