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: Peer Edits (long) From:Bob Jones <Bob -dot- Jones -at- PAREXEL -dot- COM> Date:Tue, 21 Oct 1997 13:30:21 -0400
Karen, I know what you are talking about. Last year, I worked on a
project where the review cycles went in circles and little substantive
help was given. I got some good advice from this list. Since then, I
have used and than documented the use of review teams for my company.
Up side of using review team, quality is great; down side, quality is
expensive. Attached below is what I wrote about use of review teams.
"To create the highest-quality document, use an internal Review Team
to examine your text closely. A proper Review Team process requires a
team of two or three other consultants/writers and two full days for a
100-page manual. Critical to the success of the effort is the use of
a team rather than a group of consultants/writers. The team should
consist of a leader (who may be the project manager or consultant),
content expert, and writing expert -- one person (who has good
handwriting) should act as the recorder to document all the decisions.
At least one of the team besides the leader should be a cynic. By
the end of the review process, nothing should remain which cannot be
defended -- a cynic can help to point out weaknesses.
The review team will usually review the document before the submission
of the first draft to the client. The timing may vary slightly, but
you should always present a reasonably well structured document for
the review team.
The essentials of the review process are simple:
1) Sequester the team in a conference room.
2) Agree on the purpose and structure of the text.
3) Read the entire book, line-by-line, out loud.
4) Edit, correct, or rewrite everything on a page before turning to
the next.
The role of the leader is to facilitate the meeting, to keep the
meeting productive, to enforce guidelines, and to give the final word
on all editorial decisions. As leader, it is okay to say, "We will do
it this way because I say so." This allows the process to move along
quickly. Because the review process can be tedious, the leader must
keep the team focused.
The actual review process has two types of discussion or work: the
goal-setting discussion and the close reading of the entire book.
Before starting the close reading of the book, the team must agree on
the purpose, the objectives, and the structure of the manual.
Depending on how well these have been articulated by the client, you
may find that this discussion can take several hours. Time well spent
at the beginning of a review team meeting usually pays for itself
later through productivity and quality.
After the purpose and objectives of the book are established, check to
make sure that the team members agree with the current table of
contents. As you move into the chapters of the manual, you should
establish the purpose of each chapter. Everything in each chapter
should support the purpose of the chapter -- if a section or paragraph
doesn't fit, remove it. There can be no sacred cows -- if something
does not belong, get rid of it.
Now you can begin the close reading of the text. Starting at the very
beginning of the book, one member of the team will read aloud (Be sure
to take turns). Reading the entire book aloud is a slow process, but
very few mistakes are overlooked. Pay attention for both technical
and grammatical correctness. It will be easy to find sentences that
are too long or too formal when they are read aloud. The team cynic
will usually point out any questionable areas in the text. Correct
everything before moving on to the next sentence or paragraph. At the
end of the meetings, the team should be satisfied with a "perfect"
text.
You can record your work on paper or computer. On paper, each of the
members of the team will mark all edits, corrections, and rewrites on
his/her copy of the text. The recorder of the group will maintain the
master copy of support-ready edits. You can also capture your work by
entering it on a computer with a screen projector to display the text.
The recorder will enter the edits directly onto the computer. This
method eliminates the step of sending the edits to support, but
generally, the team works and follows along more easily when working
on paper.
In some cases, you may find that your document is not in good enough
shape for a review team meeting. In order for the process to work
well, the document must be relatively well organized and well written.
Occasionally, you may find yourself reviewing a rough draft. It is a
poor use of team time to write everything as a group -- most work
should be done individually. One technique for speeding the
development of the manual is to use the team meeting to review the
tasks which must be done to improve the manual. Make a list of tasks
and assign them to team members. Then set a deadline for the
individual tasks and plan a time to reconvene as a review team.
______________________________ Reply Separator _________________________________
Subject: Peer Edits
Author: Karen Gloor-R3879Z <Karen_Gloor-R3879Z -at- EMAIL -dot- SPS -dot- MOT -dot- COM> at Internet
Date: 10/21/97 08:22 AM
Hi all!
I have been assigned with the task of putting together, and then teaching a
class on peer editing.
The group I am currently working with is quite large (16 writers), and we do
have a standards manual in place. It isn't very comprehensive, but we are in
the process of revising it. Writers do hand their work off to others for
review, but half the time, personal preferences are indicated, or writers are
looking at either content only. format only or grammar/punctuation only. In
other words, the reviews aren't too terrific.
So, I have to put together this class, and I am in need of suggestions, comments
and helpful hints. Or, if anyone knows of any good resources to use (either in
a book or on the net) I am all ears. I have already looked at Joann Hackos book
"Managing Your Documentation Projects" and I have the pamphlet from the STC on
the 5 Levels of Edit. I will also be looking for any papers or anything I can
use during the class that the writers can edit. Know where I can find anything
like that?
TIA!
Karen
r3879z -at- email -dot- sps -dot- mot -dot- com
