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.
> when do you make the last changes to the documentation?
Take into account
> that there is not code freeze where I work. When do you
say no more changes
> to be done?
There is NEVER a time. The content can always be made
better. To not do so is to assume that the document is
perfect. Anyone on the list ever, in their whole career,
ever produce a perfect document?
A document is a snapshot of the current state of your
knowledge of what you are writing about. Since I'll go on
the assumption that you always want to know more about the
subject of which you are writing, when you learn more, you
need to look at your documentation to reflect that new
knowledge.
Let's take mainframe documentation, because that's what's on
my mind right now. I create a document that explains an
add-on application to the TOS and ISPF MVS mainframe tools.
The documentation is based on what I know about it now.
OTOH, on Tuesday, I'm attending a training class directed
for ISPF support technicians. After the class, I expect to
know more about it. My next step is to revisit the
documentation to apply that gained knowledge back into the
documentation.
Other things you can consider is along the lines of
improving the index. Maybe optimizing any graphics to
decrease load time. Maybe take a procedure and try running
again from the documentation, but instead of doing the
things it says to do, do things that a novice or careless
user may try, then document how to handle the results.
There's a million things you can do.
John Posada
Senior Technical Writer
writer[at]tdandw.com