TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Editorial or Technical Review From:Robert Plamondon <robert -at- PLAMONDON -dot- COM> Date:Thu, 30 Jan 1997 08:18:04 PST
The real issue is editorial control, not editorial review. Your stance
should be that YOU are the writer/editor, and the help is YOUR project.
If you have people fighting you over commas, then you haven't arrogated
enough power to yourself. You should be in the position of a novelist
asking people to review her book. Sure, people will argue about
the commas, but they'll recognize that it's your novel, not theirs,
and you have the final say. So should it always be in the one-person
If that's the case, you really don't have a problem. Just set up the
review as follows:
* Call you help system a "prototype."
* Assert that it has errors of all kinds, and feedback on any aspect
whatever will be welcome, but that you are focusing on technical
correctness, functionality, and coverage now -- you won't
much time on commas and diction for weeks or months. Still, mark
anything that looks wrong.
This sets the stage for the kind of review you want, discourages fussiness
about editorial messages, but still leaves the door open and the WELCOME
mat out for those who really want to spend the time. It also absolves
you of any responsibility to DO anything about editorial markup until
you feel like it. (Just make sure that you don't lose any review comments,
and that you really do go over all the editorial markup when the time
I always encourage reviewers to point out anything they don't like. I
just don't give them the idea that they have any ownership of either
the document or the documentation process (any more than I feel that
I can go in and change their code).
Robert Plamondon, High-Tech Technical Writing, Inc.
36475 Norton Creek Road * Blodgett * Oregon * 97326
robert -at- plamondon -dot- com * (541) 453-5841 * Fax: (541) 453-4139