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.
Melinda Carr asked the following about frequent interim releases:
> 2) What is the best way to handle documenting these changes? Should we
> print one version of the manual for each main (e.g., 3.0, 4.0, etc.)
> version of the software and then leave everything else in the readme and
> helps? Oftentimes changes are not limited to new features--a current
> feature might change or options might be added to existing dialog boxes.
I also deal with frequent interim releases, and I handle them the way you
describe. I only rev the manual at major releases (3.0 or 3.1), but we issue a
new minor release (3.0.1, 3.0.2, etc.) about every two months. There are
usually 2-3 minor releases between manual updates. I document changes in the
minor releases in the release notes and online docs. This seems to work well
for existing customers, who are already familiar with our product when they
get an update with release notes and new online docs. However, I do worry
about how well it serves new customers, who may receive a release 3.1 manual
plus release notes for release 3.1.2 or even 3.1.3 of the product.
You also mentioned problems with the product changing significantly after the
manual has been sent to press. To avoid this problem, I don't send the manual
to press until after the code freezes. I also suggest that you attend all
product planning/status meeting and talk to the developers frequently about
how development is coming along so you'll be aware of any potential delays. I
also try to keep the production cycle as short as possible so I can wait as
long as possible before sending the manual to press. For example, I work with
a local printing company who'll pick up my files in the morning and drop off a
proof in the afternoon, and I have manual covers printed in advance.
Any other solutions?
Becky
beckyf -at- bristol -dot- com
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
