Re: Revision Control - NO! Documentation Management - YES!

[Simon North <north -at- SYNOPSYS -dot- COM>]

> > There are a number of documentation management and workflow packages
> > designed to meet these kinds of requirements. A revision control package
> > for software development is definitely not the way to go. I can imagine
> > that in some companies people might say, well we got this nice thingy
> > here anyway, so why not use it for documentation. Happened to me, but I
> > very quickly came up with 100 good reasons for not doing it, and now
> > we're evaluating a couple of real doc management packages.
> >
>
> Would you be so kind as to share the best of those 100 reasons with me
> (the list)? I'm facing the same argument now from engineering, and I am
> not sure whether the ClearCase version control system will work for our
> documentation.
>
It's a little late I know, but can I jump in on this discussion? We
have ClearCase for our software and the documentation (I'm
responsible for 23 manuals) is totally uncontrolled. My manager asked
if it would be possible to bring all the manuals into the same system
and, after checking the application note at Atria's web site, I had
to confirm that - in theory at least - Interleaf documents can also
be brought into the system...

My biggest problem is why? I've worked in software R&D departments
before and been confronted by this same question many times. Why
would you want to do this. Some reasons why not ...

- I don't want the overhead of constantly checking documents in and
out.
- I don't need detailed change management, revision bars are enough.
- I don't want to lock people out from easy access to drafts (not
everyone has access to clearcase).
- I don't need to keep old versions.
- I don't need to 'roll back' to old versions.
- I don't need multiple access control.
- I don't need auditing.

If this kind of documentation management was necessary, you'd
probably find you were doing it already using traditional tools and
kludges. A CM tool, if needed, would be very obviously needed. Be
wary of getting sucked into using a tool simply because it's there
(been there, done that, hated it). You can all too easily end up
twisting your doc production process into knots just to satisfy the
stupid tools (something on the lines of letting your servant be your
master?). I can remember, oh happy days - not, converting all my
FrameMaker files into MIF so that SCCS could handle them and turning
all sorts of somersaults to get it to make reasonable sense out of
book files.

That's my 10 cents.


  _________.__                         _______                 __  .__
 /   _____/|__| _____   ____   ____    \      \   ____________/  |_|  |__
 \_____  \ |  |/     \ /  _ \ /    \   /   |   \ /  _ \_  __ \   __\  |  \
 /        \|  |  Y Y  (  <_> )   |  \ /    |    (  <_> )  | \/|  | |   Y  \
/_______  /|__|__|_|  /\____/|___|  / \____|__  /\____/|__|   |__| |___|  /
        \/          \/            \/          \/                        \/
north -at- synopsys -dot- com (work) norths -at- globalxs -dot- nl (home)
Synopsys GmbH, Kaiserstrasse 100, 51234 Herzogenrath, Germany

 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