Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program)

[John C Klensin <[e-mail]>]

--On Thursday, April 2, 2020 11:52 -0400 Russ Housley
<[e-mail]> wrote:

>> On Apr 1, 2020, at 11:51 PM, John C Klensin
>> <[e-mail]> wrote:
>> 
>> (I've changed the subject line because I really hope we can
>> split this off and either set it aside until other work is
>> finished or find another way to handle it as an issue.)
>> 
>> --On Wednesday, April 1, 2020 19:30 -0700 Christian Huitema
>> <[e-mail]> wrote:
>> 
>>> I did not write that we should remove copy editing. But we
>>> could certainly find models in which it happens before
>>> approval, not after it.
> 
> The IESG approval process almost always leads to changes based
> in DISCUSS or COMMENT.  Sometimes these are technical changes.
> We should not do copy edits until the technical document is
> stable.  That is exactly where the copy editing is in the
> current process.
> 
> We did a few process experiments where the RFC Editor was
> invited to do copy edits earlier in the process.  Theses
> experiments did not reduce the review, approval, or final copy
> editing times significantly.  My conclusion is that the copy
> editing is in the right place in the process.
> 
> The use of the diff files has made the copy edit review MUCH
> easier that it used to be.  I'd be very happy to explore what
> other tools could make it even easier.

Russ,

I was just trying to explain that the alternative Christian
seemed to have been suggesting had been used (and was in use) in
other places and how it worked.  I was not, and would not, argue
for it for the IETF because making it work here would, I
believe, require major changes in procedures and maybe even in
culture.

An observation just in case it turns out to be useful in other
contexts.  What the Production Center does often goes beyond
what most of the publishing industry considers copy editing.  It
rarely gets far into the range of what is often described as
technical editing (or, more accurately, technical rewriting),
but it, especially when combined with changes made at the behest
of the IESG after Last Call, goes into that territory.  The
boundary, more or less, is when subject matter expertise, even
expertise on the vocabulary and basic concepts of the relevant
field and/or fairly extensive familiarity with other works in
the same area(s) is required to do the expected editing job.

The distinction is important for two reasons.  First, if all
they did was simple copy editing, we either wouldn't need AUTH48
or AUTH48 would be confined to things like misspellings they had
missed.   They do much more, they have acquired a great deal of
expertise in our documents along the line, their work is
important to us, and describing what they do as copy-editing not
only fails to recognize that but risks our slipping into the
problem of treating the RPC and its staff as just another set of
basically interchangeable contractors.

Second, my concern (and, if I understood Christian's note, at
least part of his) is that we have too many documents that get
to the end of community review during Last Call and then change
enough via IESG action or RPC efforts to be only barely
recognizable as the same document.  The changes may be
substantive ones that the IESG considers minor or the writing
styles or skills in writing technical English of some authors
may have required major rewrites of paragraphs or sections by
the RPC.  I've rarely seen either cause harm, but the fact
remains that the community is signing off on one document and
then a different document is being published.  At least in
principle, that is a risk and maybe se should be thinking about
it and whether adjustments are in order (with the understanding
that reordering the editing and approval processes is not the
only option).

best,
   john