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:question on speedy collection of engr info From:julie brodeur/mccready <jool -at- petting-zoo -dot- net> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 6 Sep 2001 12:02:37 -0700 (PDT)
Hi there, wondering if anyone had any good tips/advice on the following...
I'm currently documenting a toolkit with a large number of commands, which
the engineer changes often during point rollouts. So my doc is *always*
way out of date by the time I learn of the changes and talk to QA -- both
QA and Engr get confused on which change affects which release, despite my
best efforts at asking pointed questions and pinning down the exact usage
for the upcoming release. The confusion comes, of course, because there
are so many of these commands and minute changes in them to track and
juggle.
So anyway, I need to figure out how best to keep track of this all and
draw some line around which things I document for which release, and how
that will ultimately help the people reading the doc.
Any tips are appreciated.
Some things I've thought of:
* trying to get the engineer to add a short message to his CVS check-ins,
and setting up an auto email to me on his check-ins
* meeting with the engineer more often (difficult, because he's generally
out of the office and kinda flaky about making meetings anyway)
* breaking up the toolkit guide into portions and emailing the engineer
what i have in bite-size chunks, hoping he'll review it and send me
comments
* doing the above, but using the bugdb instead of an email
* trying to get QA person to warn me a couple days before he plans to test
the new commands so I can pester the engr for exact usage before QA tests
it
* trying to get some manager types to realize that a ton of tiny point
releases aren't as helpful as they might seem
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
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 http://www.raycomm.com/techwhirl/ for more resources and info.