http://labs.apnic.net/blabs/?p=309
an excellent detective story on badly-written, poorly edited, standards track
RFCs leading to interop problems. Enjoy.
Lloyd Wood
http://sat-net.com/L.Wood/
Technical writer and editor, native English speaker, IELTS score of 9.0,
vaguely appalled by this discussion.
________________________________________
From: ietf-bounces(_at_)ietf(_dot_)org [ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of John C Klensin [john-ietf(_at_)jck(_dot_)com]
Sent: 05 May 2013 19:32
To: Brian E Carpenter; Yaron Sheffer
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Language editing
--On Saturday, May 04, 2013 10:04 +1200 Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
On 04/05/2013 09:22, Yaron Sheffer wrote:
GEN-ART is a good example, but actual document editing is
much more work and arguably, less rewarding than a review. So
I think this can only succeed with professional (=paid)
editors.
I think I disagree, if we can find the knack of effective
crowd-sourcing. We do after all have several hundred native
English speakers active in the IETF, which would mean each one
would have to volunteer for less than one draft per year and
we'd be done.
And what we have found more times than I care to think about --
and I've found even more times than that when trying to read
undergraduate papers -- is that "native English speaker" does
not imply "ability to write good, clear, coherent technical
English". In addition, the IETF includes a reasonable number of
people whose first language is not English but whose ability to
write high-quality technical documents in English generally
exceeds that of our typical native speaker. So my first
concern is that we not start making plans based on the
population of native speakers -- if we are going to find
volunteers to pretend to be technical editors, or assess the
population of such people, we had better base our assumptions on
the right set of skills.
I don't know how much experience you have with professional
editors. Apart from the RFC Editor crew, my experience has
been "mixed". Somebody a year or three ago (the last time we
had this exact same discussion) pointed out the differences
between copy-editors and technical editors. One difference is
that the latter are much more expensive. Copy-editors tend to
be rule-driven; technical editors are supposed to understand
the material.
To be a little more precise, technical editors are supposed to
understand the nature of technical documents, to have good
intuitions about what is clear and precise and what isn't, and
so on. Specific subject-matter expertise is yet another layer
of requirement and something we would be unlikely to find far
outside the relevant WG or Area. I think the distinction
between copy editors and technical editors is very significant
(and I might have been the one who made the comment to which you
refer). But one should not confuse that distinction with the
observation that there are probably as large a proportion of
poor editors who can't deal with material that requires some
skill (in either subcategory) in the world as there are poor
engineers who can't competently handle actual systems design
issues.
Having shepherded (and kicked, clawed, and dragged) a number of
documents through the system in the last few years that were
written by people whose engineering and protocol design skills
far exceeded their [English] technical writing skills, I'm less
optimistic about volunteer editing than several others seem to
be. If a WG has surplus people with good technical editing
skills to pair with authors who may be better about the
technical details or tracking the WG discussions and getting
them into to document, then that is great. But I have certainly
worked in or chaired WGs when there are no such people to spare
or who will volunteer. In addition, it is really hard for
someone who cares enough about the subject matter of the WG to
be able to edit or translate a draft into good, clear, technical
English without injecting their own opinions about areas where
the original I-D may be unclear -- perhaps it is even harder
than writing the document with careful attention to WG consensus.
My guess is that we are going to need a mixed strategy that
involves volunteer (and adequately skilled) editors where we can
find them, professional technical editors where necessary (and a
good model for how they get paid), and oversight of the whole
process by the RFC Editor as well as relevant WG Chairs, ADs,
and the IESG. We are also going to need to be much more clear
about what level of quality we, as a community (not just the
IESG), want and will insist on before a document goes into Last
Call.
I've always hoped that the standard could be "absolutely clear
about what is being specified, but everything else can be fixed
by the RFC Editor after approval". But that requirement is more
easily stated that interpreted and used: I've seen text in
documents that I thought were that good nit-picked by the IESG
and edited by large committees and, with other documents, not
fixed (or even made worse) by the RFC Editor.
There are probably no easy and comprehensive solutions or magic
bullets.
john
Brian