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.
One of the first things I requested when starting here was access to the feature request and bug tracking systems. In addition, I got myself signed up for the weekly Knowledgebase e-mail, the provides a list of the most frequently viewed solutions for each product.
When updating documents, these are two of the places I carefully comb for topics that are insufficiently covered in the documentation, or perhaps not covered at all. Since I inherited the document set, it's not all I could wish. These resources are, IMO, an excellent resource for finding the places where the documentation needs work.
Of course, the fact that the support articles are already written makes them especially easy to fold into the docs in the appropriate places. :-)
Dan
-----Original Message-----
From: bounce-techwr-l-129804 -at- lists -dot- raycomm -dot- com
[mailto:bounce-techwr-l-129804 -at- lists -dot- raycomm -dot- com]On Behalf Of John
Posada
Sent: Wednesday, February 04, 2004 7:48 AM
To: TECHWR-L
Subject: Documentation and Bug Reports
I recently made a suggestion here and some people in the meeting looked
at my like I had two heads.
The meeting was kickoff between documentation and product management on
an upcoming release of a product. Around here, documentation has a
separate meeting with product management to get a handle on how
extensive they expect the documentation part to be and to address any
questions we may have at the beginning.
Anyway, during the meeting, my manager asked the PM, that since we were
visiting the document for the new version, was there anything else we
could address at the same time.
As part of this, I asked what does the TechSupport/CustomerSupport
logging system show as problems that if the documentation had addressed
the situation in the first place, the call might not have happened in
the first place.
It seemed that the question was comparable to lightning out of a clear
blue sky.
Within 2 days, the logging application was installed on my machine and
I'm able to analyze the reports for issues that could have been
addressed in the docs.
So, my question...anyone else doing this as a routine part of
documentation updating, review, or development?
