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: Documentation and Bug Reports From:"Chuck Martin" <cm -at- writeforyou -dot- com> To:techwr-l Date:Wed, 18 Feb 2004 09:53:59 -0800
Done it whenever the company would allow.
Now take the next step: instead of using that information to fix the docs,
use it to fix the product design.
Chuck Martin
"John Posada" <JPosada -at- isogon -dot- com> wrote in message news:227519 -at- techwr-l -dot- -dot- -dot-
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.
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.
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?
