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: managing document revisions? From:"Engstrom, Douglas D." <EngstromDD -at- PHIBRED -dot- COM> Date:Mon, 31 Mar 1997 14:30:34 -0600
Dan:
This is written in reply to:
*******************
We are making plans to correct or enhance our published documentation
with
"Documentation Updates." Previously, after we published our documents
we
just abandoned them. We make corrections in the documents for the next
software release, but customers that do not upgrade never see these
corrections.
We are concerned about the maintaining "old" versions of each document
_and_ working on a version to match the current software.
*******************
Wow, a purpose for sub-versions!!! And to think I thought they did it
just because they could...
Anyway, the document management software we use (DOCS open from PC DOCS,
Inc.) has a two-dimensional version structure. In addition to the main
versions, which are numbered, each document can have "sub-versions" as
well, which are identified by a combination of main-version number and a
letter. For example, the first release of a document will be 1A; the
next major version is 2A, the first sub-version of version 1 is 1B, the
second is 1C, the first sub-version of version 2 is 2B, and so on.
In the environment you're describing, you could use versions to
designate software-driven documentation changes, and the sub-versions to
represent maintenance of the old-version document. You can have up to
99 versions of each document, along with up to 26 sub-versions of each
version available in the document database at any given time. That
really ought to cover it.
*******************
Can someone direct me to information about implementing and managing
this
process? Perhaps in the techwr-l archives?
*******************
I'm not sure about the archives. I'm administering a document
management system here (ironically, not for technical communications as
such) and will be happy to talk to you about it. One brief word of
warning: Doc management is much, much harder than it looks, and if done
badly, you will feel like you have not only shot yourself in the foot,
but stopped to reload....
Usual vendor-website warnings: bring a rather large and heavy grain of
salt to take things with, and set your BS detector on maximum gain.....
Doug Engstrom "It's hard not to rock the boat when you're
engstromdd -at- phibred -dot- com sailing against the undertow."
--- The Indigo Girls
#######################################################################
My opinions only, not those of Pioneer Hi-Bred International, Inc.
#######################################################################
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
