Re: [Rfced-future] Welcome to the RFC Editor Future Development Program

[Christian Huitema <[e-mail]>]

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.

-- Christian Huitema 

> On Apr 1, 2020, at 7:22 PM, Joel M. Halpern <[e-mail]> wrote:
> 
> Christian, I am a bit confused by your message.  Removing post-approval editing, while it would reduce tension and delay, would also significantly reduce document quality.  The RPC does an impressive job of fixing the many minor but significant errors we put in our documents.  Ranging from inconsistent terminology to really bad grammar.
> I, for one, would be really unhappy at trying to decide we did not need that.
> 
> Yours,
> Joel
> 
>> On 4/1/2020 9:39 PM, Christian Huitema wrote:
>> On 4/1/2020 5:38 PM, Larry Masinter wrote:
>>>> I hope this process can find a way to deal with such divergent views, or find
>>>> a role description with which we are all equally unhappy, but with which we
>>>> can all live;-(
>>> I think the question is how big a scope of "solutions" should be taken on.
>>> At the "large scope" are changes to the nature of RFCs and the series
>>> At the "small scope" end I'd suggest -- without any other change -- focusing on the "AUTH48" status since 48 hours and only the authors cannot proofread everything that needs proofreading.
>>> 
>>> (History RFC2616 had several errors that were due to bugs in the process of converting Word to text/plain)
>>> 
>>> I can't tell from the posts and intro material what level of changes to the process you'd want to contemplate.
>> There is indeed an issue with AUTH48, but there is a more general issue with "changing documents after consensus is declared".
>> For the IETF stream, the current process puts the final phase of editing after the final vote by the IESG. This is a source of both tensions and delays. The tension is obvious: if a document can be changed after it has been approved, how do we guarantee that the changes do not change the meaning of the documents in a way that alters consensus? The process puts that responsibility on the authors and the AD, but the authors may or may not have the time to examine the changes closely, and the AD may or may not be already overloaded. So that create delays, not because the copy editors are slow, but because the authors and AD end up responding slowly.
>> Removing tensions and delays would make life easier for everybody.
>> -- Christian Huitema
> 
> -- 
> Rfced-future mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/rfced-future