Re: [Techspec] When to do pre-edit
John C Klensin <john-ietf@jck.com> Thu, 25 May 2006 15:13 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHWo-00040k-8y; Thu, 25 May 2006 11:13:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHWn-0003y0-MW for techspec@ietf.org; Thu, 25 May 2006 11:13:33 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHWm-0001TM-7A for techspec@ietf.org; Thu, 25 May 2006 11:13:33 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FjHWl-000PJn-Jm; Thu, 25 May 2006 11:13:31 -0400
Date: Thu, 25 May 2006 11:13:30 -0400
From: John C Klensin <john-ietf@jck.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, techspec@ietf.org
Subject: Re: [Techspec] When to do pre-edit
Message-ID: <3CFB3870B1123FD216C073B6@p3.JCK.COM>
In-Reply-To: <p062309d2c09a5252afa2@[10.20.30.249]>
References: <p062309d2c09a5252afa2@[10.20.30.249]>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc:
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" <techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>, <mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>, <mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org
--On Wednesday, 24 May, 2006 11:15 -0700 Paul Hoffman <paul.hoffman@vpnc.org> wrote: > In section 3.1: > o Req-PREEDIT-1: The IETF technical publisher should > perform an > editorial review of documents before WG last call and > provide > feedback to the authors to improve quality of the > documents. This > review should strive to maintain consistency in > appearance with > previously published documents. > This requirement might be modified to read "...documents > before or during WG last call...", because some WG chairs may > not know when a document is ready for WG last call until the > last minute, and making them wait for the WG last call could > be inappropriate. The technical publisher should help WG > chairs understand that doing this review during WG last call > could result in many more changes than they expected, but > still let the WG chairs make the decision when to have the > review done. It is also worth pointing out that we do not require WG Last Calls and that this stage does not exist for individual submissions of standards track documents. Modulo Paul's comments (with which I agree) and the concern below, I think this suggestion is generally a good one. But the text needs to be adjusted to be consistent with the real variability permitted by our present approval processes. The concern is that, at any given resource level, there will be only so many resources to go around. There has been an active concern, partially reflected in the POSTEDIT materials, that we shorten the gap between approval and final publication as much as possible. That requirement is going to put the Technical Publisher into a position in which, on any given day, a choice will need to be made between having a person-resource working on getting approved documents out or having that person engaged in a pre-approval process that, in the worst case, may involve administering individualized short courses in English Composition. The latter process may well be worthwhile, but is often immensely time-consuming. I also note that some documents have been put through WG last call, which has turned up objections leading to significant modifications and another WG last call. Sometimes that cycle has been repeated. I don't understand from the above when we would expect the Technical Publisher to intervene and how many times. To the extent to which this document is expected to be transformed into RFI, RFP, and/or contractual language, sections like the above should be transformed from "wish list" into things we understand how to implement in terms of priorities and resources. In addition, I suggest that an individual or organization could be skilled and well-equipped to do the editing and publication part of the job without having the skills or inclination to "provide feedback" that amounts to training in English Composition and clarity of presentation. If we insist that the Technical Publisher entity contain both sets of skills, we may be unreasonably overconstraining the set of possible applicants. Perhaps it would be worthwhile to keep this task, but figure out a way to accomplish it that is not part of the Technical Publisher role and hence does not get into the critical path of getting documents published post-approval. The text, as written, certainly does not permit that. john _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec
- [Techspec] When to do pre-edit Paul Hoffman
- RE: [Techspec] When to do pre-edit Stephen Hayes (TX/EUS)
- Re: [Techspec] When to do pre-edit John C Klensin