Documenting Betas and Finals

[Esther Wheeler <ewheeler -at- AZURE-TECH -dot- COM>]

Hello, I'm a lurker who values the relevant information that
often appears on this list.

Valarie Tassari writes (of freezing and hanging terminology):
"If you are able to consistently recreate this behavior, the
system is not ready for release."

Well, yes. In an ideal world all releases would be completely
bug-free, or at least not quit unexpectedly (now _there's_ a
polite phrase for you).

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?

I have (in the past) worked on products which I feel have glaring
user interface problems. However, if engineering thinks it "gets
the job done" they may want to release anyway. I try to get in
early and make a lot of user-friendly noise to cut down on this.
Sometimes you can find an ally, like in marketing. But I'm
always looking for techniques that work -- or even funny stories.

[I loved the piece Dick Dimock wrote on training and docu-
mentation and even forwarded it, with attribution, to other
appreciative peers with the title "It's all too true...")

Esther Wheeler
Azure Technologies
ewheeler -at- azure-tech -dot- com