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.
> Did some searching for this topic in the archives, but
> didn't come up with anything. At which point do you
> determine that your document has moved to a different
> version? For example, when do you go from 3.3 to 3.4,
> or from 3.3 to 4.0? Is there a set of standards that
> has been published somewhere?
Chantel writes:
I'm not sure if there is a standard (someone will probably come forward if there
is one), but I'll share a method that seems to
work pretty well for our group.
First the basic rules.
*The version number of the documentation matches the version number of the
application you are documenting.
*Within each version, there are different drafts -- the first one is simply
"draft," the second "preliminary," and the third "final."
*Each document is dated with the completion (delivery) date.
Now the example.
Let's say I start documenting a piece of software named EASYTECH, Version 1.3.
There is no documentation, so I start
writing the user manual from scratch. After my first cut, I give it to the
engineers/project manager for review. On the cover
page of the document I assign the following title: "EASYTECH User Manual,
Version 1.3 -- DRAFT (12 Oct 2000)". When
the corrections come back, I make them. If another review is needed, I mark the
document "EASYTECH User Manual,
Version 1.3 -- PRELIMINARY (5 Nov 2000)" When it is finally complete and ready
to be shipped, the document is marked
"EASYTECH User Manual, Version 1.3 -- FINAL (30 November 2000)" (Or leave it
off -- internally we know it is the final
draft though.) It is helpful to add the dates because if you have a several
preliminaries (or finals) you can differentiate between
them.
What I like about this approach is that there aren't a lot of numbers to track,
you don't have to worry about how to assign
numbers, you know at a glance the development stage of the documentation, and
you always know for which version of the
software the manual has been written.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at http://www.devahelp.com or info -at- devahelp -dot- com
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
