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.
(Responding to digest - forgive me if others have made
I have to agree with Jim Shaeffer - developers and
engineers really don't have the knowledge to determine
the documentation impact of a bug. To assess the
impact, you need to know these things:
- What did we say about this before?
- What will customers see?
- How are we addressing this?
You, the information specialist, can answer the first
The person reporting the bug MAY be able to answer the
second question - but you may need to observe the
issue to understand how a customer experiences it.
Product management may define how the issue needs to
be addressed; ultimately the developer who fixes it
will have the most detailed information. Again, you
may need to observe the fix to understand how, where,
and even whether to describe it.
As a lone writer in a small company, I've found it
helpful to befriend the development team and remind
them from time to time that I need to know about any
change that customers will be able to perceive. It's
also been helpful to set up a documentation category
in the bug tracking system - this shows my development
team that I understand how to use it, and that I'm
willing to play by their rules.
It doesn't hurt that in a year, there have only been
24 issues logged against the documentation, and the
only high-priority issue among them was advance notice
of a known issue to be documented - not a correction.
You can use the bug database as one of your process
tools. (Yes, you need processes even if you are a
one-person department. :-) If you dump the bug list
for a given product version into a spreadsheet, you
can add information that you need - such as
explanations, documentation impact (if any), and names
of subject-matter experts - and you can shade rows as
you document the issues, so you know which ones you
still need to research and document.
We are uniquely qualified to determine what subset of
the information in a bug database is relevant to our
customers' experience, and to translate the geek-speak
of bug descriptions into our customers' language.
This is what we get paid for, and it's how we disprove
the notion that "anybody can write documentation" - by
demonstrating that we are *technical* *communicators*.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-