[Author Prev][Author Next][Thread Prev][Thread Next]
[Author Index (this month)][Thread Index (this month)][Top of Archive]

Re: meaning & practice of a "doc freeze"

Subject: Re: meaning & practice of a "doc freeze"
From: Bob Perrey <rperrey -at- sbcglobal -dot- net>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 08 Apr 2004 10:46:00 -0700


When I was still contracting I always insisted the specifications for a document be "etched in stone" lest new information force a longer involvement with the documentation, and hence more hours than originally predicted. This provision did save controversy when, later on, a client introduced changes and then complained about the additional billing. I admit this description slightly skirts the question as you asked it, but on the other hand, I mean to imply no "freeze" is necessarily frozen, and the writer should be prepared for that. If one is a staff writer, one quickly learns that no doc is frozen until final manufacturing. The best projects I have had have involved two documents for a single product: the first is a Technical Specification document in which all the design elements are approved for coding. That way the final document can always remain fairly constant, despite coding approaches to internals that may change.

Bob Perrey


At 06:28 4/8/2004, you wrote:

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

So my question is, once you have produced a "final" after the freeze date,
do you then submit the final back to the SMEs or developers? I ask because
if I do this, they still want to make changes. So why should we submit a
"final" to them at all at that point? Why not just call it done & send it
to the release cycle? And if the SME's/Developers want to see the final,
they can look at it in PDF format on the network. The rest of the
development team misunderstands the meaning of "doc freeze" if they believe
they can still have input to the doc after that. So what are your
practices? To submit, or not to submit, a final after the "freeze"?

Comments?

Thanks!





_____________________________________
// Bob Perrey, Publisher
// R. Travers Press
// rperrey at sbcglobal dot net
// Outgoing messages scanned for viruses.
// Sisyphus too was happiest between gigs.



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

ROBOHELP X5 - ALL NEW VERSION!!
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!
Download a free trial today: http://www.ehelp.com/techwr-l4

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


References:
meaning & practice of a "doc freeze": From: stacy naus

Previous by Author: RE: Illustrations in electronic publications and paper editions
Next by Author: Personification
Previous by Thread: RE: meaning & practice of a "doc freeze"
Next by Thread: RE: meaning & practice of a "doc freeze"

[Top of Archive] | [Author Index (this month)] | [Thread Index (this month)]

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

Sponsored Ads