Re: What to look for in a technical editor

Subject: Re: What to look for in a technical editor
From: Chris <cud -at- telecable -dot- es>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 21 May 2003 09:56:28 +0200

I think you missed a statement I made (or at least I *think* I made it)... I also never worked with an editor who actually changed my work. That is my responsibility, not the editor's. So I don't have to go through and find subtle changes to undo - I simply have to consider the editor's markup and explain myself if I choose to reject a change. (PDF is a great medium for this, BTW.)

The other point was made that even considering and explaining a rejected change is a waste of time. I disagree. If the editor noticed a problem, then there probably is some problem in there - you can probably improve the phrase. If the editor makes a consistent error (fixing caitalization in source code?!), you can visit the editor and point that out - your editor will become more effective for everybody, and your relationship will improve.

An editor is a great resource. If you don't know how to take advantage of the resource, shame on you.

Ok, so it's possible that you're working with a bonafide idiot. That has nothing to do with his job title - an idiot is an idiot and makes your life miserable no matter what his function is. Document the problem, make you case, and move on.

Chris wrote:
Also, I have *never* worked with an editor who insisted on a structure or passage that I could demonstrate was technically inaccurate. And I have worked with at least one of the editors who has responded to this thread.

Me neither. But it's not the fact that an editor will insist on a structure or passage that you/I/anyone could demonstrate was technically inaccurate. It's more a problem of having to go back through your document and undo the changes an editor makes if those changes are technically inaccurate. In some cases, this can take a lot of time if the changes are subtle enough but still affect accuracy. In the very least it's a waste of the writer's time and the worst, it's a waste of the company's money. And before you say "Use track changes," it's still still an unpleasant experience that could be avoided.

That's what bothers me at least as a writer.

Chris Despopoulos, maker of CudSpan Freeware...
Plugins to Enhance FrameMaker & FrameMaker+SGML
cud -at- telecable -dot- es


Robohelp X3, from eHelp, lets you quickly and easily create professional Help systems for all your Windows and Web-based applications, including Net.
Order RoboHelp X3 in May and receive a $100 mail-in rebate, PLUS
free RoboScreenCapture and WebHelp Merge Module.
Order RoboHelp today:

You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit for more resources and info.

Previous by Author: Re: What to look for in a technical editor
Next by Author: Re: techwr-l digest: May 21, 2003
Previous by Thread: RE: Re: What to look for in a technical editor
Next by Thread: Re: What to look for in a technical editor

What this post helpful? Share it with friends and colleagues:

Sponsored Ads