FW: Automating docs compilation in the software build process

Subject: FW: Automating docs compilation in the software build process
From: "David Locke" <dlocke -at- texas -dot- net>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 22 May 2003 06:07:55 -0500


What is missing here is check-in and check-out times. It will take you, if
you have a good sized help system, thirty minutes or more every morning of
every day for the rest of your life to check out those files so you can work
on them. It may take less time to check them back in.

No, you don't get a free hour here or there by automating this function.
It's a function that took five minutes when you only checked in the compiled
help and the Acrobat version of your print manual. Now, it will take
forever.

We never finished the help in sync with the developers. It is still a throw
it over the wall process. Doc isn't meaningful until some time after code
freeze. There will be times when you need a compile and daily builds are not
being done, like during the last QA cycles. And, we didn't want QA to write
things up until we were finished. By not doing a daily build we reduced
spurious track bugs. The review problem is huge especially if you have to
have a legal review along with editorial reviews. Legal reviews held up
shipping more times than I could count. They could not meet their schedule
agreements. We only checked in completed content and we didn't do that every
day. Even our read me wasn't finished until the final build and we had to do
link checking before the final build was shipped. We were the gate.

Still, if you want to automate it go ahead. Just figure out how to speed up
check in and check out. Batch files help. You might be able to store the
files on a server and automate the check in and out from there at say 3 am
in the morning unless you have writers pulling all-nighters. By scheduling
the check in and check out it could be finished and the files could be
accessible, so that you don't spend all morning waiting for them to be
accessible. You might even use a staging server, so any all night writers
could keep on working on server A while server B checks in and checks out.
Working writers would just drag their files over from server A to server B
when they finish with them. They could do this at 2:30 am without impacting
their work.

David W. Locke



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Robohelp X3, from eHelp, lets you quickly and easily create
professional Help systems for all your Windows and Web-based
applications, including Net.

Order RoboHelp X3 in May and receive a $100 mail-in rebate, PLUS
free RoboScreenCapture and WebHelp Merge Module.

Order RoboHelp today: http://www.ehelp.com/techwr-l

---
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.



Previous by Author: RE: What to look for in a technical editor
Next by Author: documenting parametised messages
Previous by Thread: Re: Automating docs compilation in the software build process
Next by Thread: Re: What to look for in a technical editor


What this post helpful? Share it with friends and colleagues:


Sponsored Ads