--On Saturday, May 04, 2013 10:04 +1200 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> 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