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