Politeness in editing
by Geoff Hart*
[Editor's note: "Politeness in editing" was the topic of one discussion on TECHWR-L in December. Here is a slightly edited version of Geoff Hart's comments on that list.]
How to express or justify an edit depends strongly on your relationship with the author.
In my day job, the authors have 8+ years of experience learning to trust my edits, and thus, I don't have to spend a lot of time sugarcoating things--though I did a lot more of this when I was getting started here as part of the process of building a collaborative, mutually respectful relationship.
But in my freelance work, I'm usually editing the writing of authors I've never met and will never meet, and may only get to edit a couple of their papers over the course of a professional lifetime; worse yet, they're writing in a second language (English) and are somewhat sensitive about their skills (which are often quite good, but occasionally appalling). That being the case, I have no pre-existing relationship with them, and need to go the extra few steps to reduce the inevitable friction that arises when you tell someone (however politely) that they shouldn't quit their day job to take up a writing career.
Where I must repeatedly add a politeness phrase of some sort, I usually
either invoke it
While my editing may be brutal (because of length constraints, I commonly have to chop 30-50% of the words from some of the manuscripts I edit; I often have to point out that the author's logic is sadly lacking), there's no reason whatsoever to be brutal about how I express the edits.
Consider, for example, the difference between "do you mean... [proposed rewording]? if not, please reword to clarify" and "incomprehensible; rewrite". The first shows that you've made an attempt to understand and have proposed a solution (which, if incorrect, at least shows the author why their original is unclear); the second simply slaps the author's wrist and leaves the problem in their hands.
Another important point: if you're in the position of being able to dictate changes to the writer being edited, then you have considerably more leeway to impose your changes without having to explain them. You'll still work more effectively with your authors if you negotiate and explain, but you don't really have to do this.
If, like most of us, you have to negotiate changes, then it's important to develop good persuasive skills and a collaborative, consensual relationship with authors since you can't impose your choices on them.
These two situations represent the extremes of editorial power (manager-editor vs. peer editor), but there are obviously many intermediate situations. Where I work, for example, our deal is currently that authors must come see me to discuss any changes they disagree with, but can accept all other changes with no discussion. This builds a more collaborative approach, particularly since I'm willing to work with an author to help them come up with their own solution, which we can then adopt, rather than simply browbeating them into accepting my suggestion.
One advantage of commenting on why you made a change is that this also serves an educational role. Authors may not always learn quickly, but they do (after enough exposures to my rationale) begin to avoid repeating certain types of mistake, and that makes them better writers and lets me concentrate on other problems.
I've become a much better writer by paying attention to several skilled editors who have greatly improved my writing over the years. Moreover, paying attention to my own occasional "are you nuts???" reactions to edits have taught me a great deal of empathy for those whom I edit. After all, it's hard for me to wallow in and enjoy my own emotional responses if I don't acknowledge the rights of my own authors to feel the same way. Given how heavily I edit, they're occasionally (frequently!) going to be responding to my work on a more than purely logical level.
* Geoff Hart contributes the monthly "User's advocate" column http://www.raycomm.com/techwhirl/usersadvocate.html
Article © Copyright 2002 Geoff Hart