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: Bugs in Documentation From:Ruth Glaser <ruthg -at- GORETEK -dot- COM> Date:Thu, 6 Jun 1996 13:24:13 -0500
Grant Hogarth raised a good point when he responded:
------
*I* like to know how other folks *Get* the bugs in the docs reported
to them... and how the bugfix gets reported back upstream.
------
When a change needs to be done to a particular piece of code, the bug or
enhancement is written up on a work request (WR). Then a programmer, qa
analyst, and tech writer all review it, add their detailed notes and design,
& put estimates on it. Then after some marketing vs. development arm
wrestling, it may be scheduled in the next project plan.
When the WR is complete, a programmer, qa, and writer must sign off on it.
We use an inhouse program that allows us to track this quite well, which is
how we report "upstream".
This process lets us plan for upcoming changes to docs that are due to new
programming.
OTOH, when a bug or change is identified in docs, it is also written on a WR
and then comes to the writer for details/design and estimates. (Oftentimes a
support person will call me or write a note that says something like, "Did
you know that this field really defaults from this file, but the docs say
XXX?" Then I'll figure out the problem & write a WR.) Then there's more arm
wrestling and it may go into the next release, if time allows. But these are
*generally* a lower priority than a change made to docs to accomodate a
programming change.
I guess we can assume that docs bugs cause fewer problems for our customers
than programming bugs in our product. ;-)
I think the important thing is to be open to this type of input. Also, I'm
always sure to tell the person who reports docs bugs "Thank you very much.
This is the process: _________. It may or may not get fixed. But please keep
the info coming." This helps set the proper expectations.
Ruth
--
Ruth T. Glaser e-mail: ruthg -at- goretek -dot- com
Goretek Data Systems, Inc. Phone: (612) 639-5043
900 Long Lake Road #151 Fax: (612) 639-5090
New Brighton, MN 55112 WWW: http://www.goretek.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net
