Re: [IAOC] RFC Editor costs - Proofreading (was Re: My view of the IAOC Meeting Selection Guidelines)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Feb 9, 2008, at 1:46 PM, Dave Crocker wrote:

> My own assessment is that it has improved the documents. The  
> proofreaders have
> their own views of what is correct and that sometimes requires  
> discussion, but
> mostly I consider their intervention to have a positive impact.
>
> The question to me -- and which I am posing to everyone else -- is  
> whether the
> improvement is worth the cost?

Speaking strictly for myself...

Over the past year or so, while we have been using this service, the  
RFC Editor has been able to clean up the backlog. To my knowledge, we  
have made no other changes to the RFC Editor's office. Speaking  
absent data - the RFC Editor's office is largely a black box to me -  
that suggests that improving the quality of what goes in reduces the  
time it takes to produce what comes out.

Now, that brings several possibilities to mind. One is to suggest  
widening the pre-processing effort. Another is to suggest that the  
pre-processing effort is successful with the resources applied, and  
so needs no widening. A third is to suggest that the RFC Editor  
increase its copy-editing staff, drop the *separate* pre-processing,  
but encourage the RFC Editor to skim documents that show up in the  
IESG's workload and opportunistically start its editing processes early.

I have occasionally found myself wondering whether a grammar checker  
that could read our XML files (about 1/3 of our posted drafts have  
XML source posted with them) and make suggestions would be of value.  
In converting what is now RFC 1716 to RFC 1812, which was a HUGE  
editing task, I used a brand new tool that is now a popular grammar  
checker. It complained about "which" vs "that", which is neither here  
nor there, but also complained about misspellings, passive voice, and  
sentences that it couldn't parse. Apart from the technical  
differences (changing "subnet" to "prefix" and applying then-new CIDR  
concepts, deprecating RIP, etc), the vast majority of the changes I  
made could be described as copy-editing in response to those  
complaints, and folks seemed to think the result was an improvement.  
With the new posting tool, the idnits checker is run against every  
submission, which simplifies the life of the document shepherd. If  
the upload includes an XML file, would it make sense to similarly  
grammar check it, which the result being advice for the document author?

As you say, the heavy lifting has to be done by people that  
understand the semantics. But there are ways to improve the syntax,  
and as I say, the available data would suggest that improving what  
goes in to the RFC Editor helps them produce the output.


_______________________________________________

Ietf@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]