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: Error management in documentation From:"Renee L. LaPlume" <rlaplume -at- rorke -dot- com> To:TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM Date:Tue, 19 Oct 1999 10:29:33 -0500
At 10:42 AM 10/19/99 -0400, you wrote:
>To a question about tracking documentation errors and
>subject-software bug fixes, for inclusion in upcoming
>releases of the docs, Janet Valade ventured:
>
>> use the same process the developers use
>> to track product bugs. Usually, it is some kind of database
>> in which bugs are logged and tracked. If you monitor the bugs database, you
>> will know the identified bugs and will know when/if bugs are fixed. You can
>> use the same database to log "bugs" in your docs. And track the versions
>> of the manual in which the "bugs" were fixed. This is helpful for technical
>> support, as well.
>
Kevin McLauchlan went on to describe how at his organization...
> The developers record *everything* in their database, so
> there is no searchable/filterable distinction between
> formal "bugs" in released software, and glitches,
> suggestions, explorations, afterthoughts, etc. that go
> along with the in-house development process.
<large snip>
We use descriptive fields for the bugs so they are classified
by module and status. We're looking to implement a new
system that will better incorporate work flow, so that if it
is set up correctly, one should be notified of only the items
that affect you (specifically, we're considering TeamTrack--
see the www.teamshare.com web site for information on it).
The work flow can be set up so you are notified of new
items only or of changes to items, of certain products/modules etc.
I think in our new system (whatever we choose), we'll add a
a classification for developer-only bugs. Also, there should
be a field for product, so that if a bug is for an internal
tool, that should be apparent by the name of the product in this
field. Not sure about what you're saying about keywords, but
if the categories, statuses, and work flows are set up correctly,
the information should flow to you in a more organized fashion.
HTH,
Renee
P.S. I administer our current bug tracking system (a homegrown
system we have outgrown) and will be evaluating the new system
we pick, so I am actively involved in our bug tracking.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Renee L. LaPlume
Rorke Data, Inc. - Software Services Division
- - - - - - - - - - - - - - - - - - - - - - - - - -
