Re: where do docs fit in the development process?
At 7:35 AM -0800 1/28/02, Andrew Plato wrote:
"Susie Pearson" wrote...
Where I work, they want the
final docs at the same time the release candidate is
Sounds normal to me. Makes perfect sense to have docs done at RC1.
I take exception to this comment made by Andrew. It is NOT normal to have "final" documents ready at RC1. This is a test. The software isn't even final yet.
Heaven forbid I agree with Andrew, but the real issue might come down to the meaning of "release candidate" and "final documentation". In previous groups I've worked in, we published with the software release, and the documentation release had the same intent and quality as the software release. (Now our group publishes quarterly, with new features documented in the quarter BEFORE the beta/RC/release becomes available)
In that previous situation, a Beta release of the product had Beta documentation. It was as complete as possible, and sometimes indicates where things were missing. However, it was not expected to be 100% bug-free. Part of the goal of Beta docs was to get feedback on things customers want, or emphasis and organizational changes they'd like.
Release Candidates were the same way. They were expected to be feature-complete, with no significant bugs. The docs were expected to be the same. Since the docs were packaged and shipped with the "whole" product, then the docs had to be as release-worthy as the software. The intent of a Release Candidate was that, if none of the customers/partners evaluating it came back with significant problems, and if no additional problems were found internally, then that build would be released as the final product build. If the docs weren't ready for the RC, then that would require another build to update the docs, which means that the shipped product would not actually be the same build as the release candidate. This would force another several-week testing cycle, since, after all, it's the final build of the product. That single, unique build had to go through a full test cycle with no changes and no significant problems found.
So yes, the docs should be in as good a shape as the rest of the product for all releases, including Beta and Release Candidates.
However, some companies don't really have release candidate-quality product when they put such out there. They are more Beta-quality, and sometimes even worse. If you haven't had sufficient time with a stable product to finish the documentation, then it's likely the test team has not had that time either. If that's the case, and the developers and management expect significant bug fixes to come in on the RC, then it's not a viable release candidate. Your docs should be expected to meet the same quality level as the software. Likewise, the product management should not expect to ship the product until the "code" and the documentation are at release-quality level.
Attention ForeHelp and Doc-to-Help Users! Upgrade your existing product to
RoboHelp for only $299, through January 31st. RoboHelp can import your
existing Help projects! Learn how else RoboHelp can benefit you. www.ehelp.com/techwr
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: Speaker's Notes in PowerPoint
Next by Author: RE: Client woes: a question to ask yourself...
Previous by Thread: Re: where do docs fit in the development process?
Next by Thread: RE: where do docs fit in the development process?
Search our Technical Writing Archives & Magazine