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: Maintaining a Readme From:Matt Donovan <Matthew -dot- Donovan -at- ALCATEL -dot- FR> Date:Wed, 9 Jun 1999 17:51:26 +0200
Item Subject: Maintaining a Readme
Hi Gerry.
The bad news is, yes, readme's do go into the build.
Having worked on readme's all I can say is that when you're near
release time, they are hell.
What goes in them depends on your program manager.
Some only want technical info you didn't get in the book, soem want
ANY damn thing you couldn't get in the book.
The best idea is define this with the project leader BEFORE you start
sweating at midnite because a build is going to beta-phase.
To give an example, taken from real experience in a former company:
Once all the docs were ready and delivered to the integration dept for
the build (compiled HTML help, parallel HLPs, PDFs, etc) I had to sit
around with my co-worker (who dealt with other language readme's)
waiting for the "last minute info". This was an extremely tense time,
as we had nothing else to do except wait for the info. Often, we had
to wait three hours to find that the planned build didn't pass QA, and
that the developers still had work to do before the next (and final
???) build. This was even more complicated since we had three readme's
per language (client/server/Intranet).
Finally, a project leader would come to us, give us the info we
needed, then it was hell for leather to prepare the readme's for the
"last" build".
OK, this was in a small company, but I'm sure the problems are the
same even in larger outfits.
I would be very interested to know how others handle readme's.
Matt DONOVAN
Technical Writer
______________________________ Reply Separator _________________________________
Subject: Maintaining a Readme
Author: GBourgui at SHAR/DD -dot- RFC-822=GBourgui -at- LAVASYS -dot- COM
Date: 09/06/99 17:26
How do you deal with last minute information that needs to go into a Readme
file?
We use the InstallShield product which provides the user with the option of
viewing the Readme at the end of the installation so, as far as I know, the
Readme must be included in the build. Therefore, if the Readme changes
(which it often does), a new build must be generated (and subsequently
tested). Is there a way around this?
On a similar note, what should the Readme contain? The Readme I am
currently maintaining contains information that should perhaps go elsewhere.
For example, it includes installation/upgrade instructions along with
platforms and software supported, known issues, etc.
