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:meaning & practice of a "doc freeze" From:Chris Gooch <chris -dot- gooch -at- lightworkdesign -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 13 Apr 2004 15:12:48 +0100
Stacy asked:
+++
Does anyone out there use a "documentation freeze" approach in their doc
development/production strategy? My understanding/practice
is that a "doc freeze" is much like a code freeze;
no new content or changes are accepted from the Subject Matter
Experts/developers. BUT if we go with that definition, then the practice is
this: during doc freeze, you are then still making revisions (due to the
fact that revisions were submitted up until the date of the freeze).
+++
Stacy -
(sorry about the delay, easter bank holidays in the UK)
The point of a docs freeze, IMHO, as with a code freeze, is not so much
that no new work can be done (I'd call that a docs / code "halt" rather than
freeze, but different shops have different terminology), but that no new
work is done without your consent; it's a change of ownership if you
like. With a code freeze, as others have said, this normally means that
no _new_ development is done; the time between code freeze and
code halt is then used for a test-fix-test cycle. You can view this as
a passing of ownership from development to QA, such that the only
changes to be made after code freeze are at the request of QA.
A docs freeze is entirely analagous in that the docs manager needs to
call a halt to the addition of new docs into the docs set so that time
can be spent in the final proof-fix-proof cycle. This doesn't mean that
you wouldn't document something you noticed was missing during
proofing; but it does mean that you've entered a phase in the development
cycle whereby nothing should be changing without the docs manager
knowing about it, and knowing/agreeing the justification for it.
I generally call a docs freeze a few days before shipping, no earlier
than that, and a couple of weeks after code freeze (I find that SMEs
are very amenable to helping with docs work after code freeze since
it's either that or bug fixing!). Of course, people know it's coming, so
there shouldn't be any major new documentation to be done after the
docs freeze, I just use the time to do the finishing touches.
hth,
Chris.
Christopher Gooch, Technical Author
LightWork Design, Sheffield, UK.
www.lightworkdesign.com
Have you tried the latest in Help Authoring from RoboHelp?
Try ROBOHELP X5 for Free - Now with Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more!
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.
