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: Gathering edits from several people From:"Dan Roberts" <droberts63 -at- earthlink -dot- net> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Sat, 22 Jan 2000 09:32:50 -0500
a good system. An additional advantage is that the group review ensures that
everyone agrees what the documentation will contain. It can help prevent the
'put it in" "take it out" "put it back in" take it back out" cycle of
documentation. ("Words words words, I'm so sick of hearing words--first from
him, then from you, is that all you blighters can do?" oops started
channeling Eliza Doolittle there).
Group meetings can also help resolve different visions of the book. For
example, I've got an MVS tool that can be run by JCL or by an ISPF
interface. Up till now, the focus of the doc has been on the JCL and the
words and internal processes and what the program is doing to the data it
finds before it gives you the answer you want. Pretty text heavy. Now,
product mgmt has decided to doc the tool from the UI point of view--"enter
this here, select that option, submit, go have a coffee while you wait for
your answer." A right decision, imho, but I know the programmers are gonna
squawk. So a group meeting/review with mgmt and development will help squash
that dissention. Of course, I could spend time with the developers
convincing them how right this decisioin is, but unfortunately, I dont have
that luxury in this case.
And so it goes..
-----Original Message-----
From: Beth Kane <bethkane -at- tcisolutions -dot- com>
>
>1. All reviewers are given a hard copy and are asked to mark up all trouble
>areas -- not necessarily with detailed notes; brief notes or even an X
might
>serve the purpose.
>2. The tech writer schedules a meeting. All reviewers bring their marked-up
>copies to the meeting.
>3. All present go through the document
>4. When an issue arises, everyone is present to discuss and resolve it. The
>tech writer makes notes on her/his own copy that incorporate everyone's
>feedback.
>7. The tech writer takes her single copy of
>notes and immediately puts the agreed-upon changes into the manual.
>8. The SMEs retain their own copies, so if they want to check the final
copy
>later to make sure their corrections got into it, they can.
