documenting freeze, etc and changes for beta

[Valarie <TASSARI -at- CGI -dot- COM>]

>>On Tue, 14 Nov 1995 10:50:06 -0800 John Wilcox <john -at- SYNTAX -dot- COM> wrote:

>>Does the smiley at the end mean the whole post was just a joke?
...
>>But if this WAS just a joke, thanks for the laugh!  It's the funniest
>>thing I've read in a long time!

John, I'm glad that I was able to bring a smile to your face.  I'm hardly
joking however.  The smile was intended to compliment the writer on a good
effort in an uncomfortable situation and not make a mockery of the QA
process that *should* take place during software development, nor to
belittle anyone else's software practices.

I think you missed the words "consistently recreate" in my message.  At my
company, if a "crash, freeze or hang" bug is uncovered during the QA
process that can be repeated using the same keystrokes, then this bug is
fixed BEFORE the software is released or the release doesn't happen.  This
is considered to be a priority 1 bug which must be fixed for the software
to be "ready".  I am never asked to document in the release notes that a
certain procedure will cause the system to hang or freeze.  Our group is
not very big, nor is the software distribution as wide spread as we would
like.  We have learned _the hard way_ how devastating it can be to the
reputation of the group and the company when inferior software is released.


>>On Tue, 14 Nov 1995 12:18:57  Esther Wheeler <ewheeler -at- AZURE-TECH -dot- COM>
>>asked:

>>I'd like to pursue a slightly different angle on this thread. Many
>>of us do document less-than-ideal products, in the best cases
>>simply for evaluation (alpha and beta releases). I'd like to hear
>>how other writers in this situation push back on engineering
>>before these unsightly products get to release. What approach
>>gets you the best results?

We do alpha and beta releases also.  ...and, to set the record straight, we
DON'T have perfect software.  The biggest factor I have found in swaying
engineering is to become an integral part of the group.  You can become
their friend, earn their trust, and their respect.  I'm involved from spec
writing to interface design to final release.  I believe I'm very lucky.
Also, one of the engineers in our group is a "human factors fanatic", so
it's pretty easy to influence the development.

Keep up the good fight!

Val Tassari
Sr. Technical Writer, Carnegie Group, Inc.
tassari -at- cgi -dot- com