Re: methods of reviewing documentation

["Mike O." <obie1121 -at- yahoo -dot- com>]

Mark Baker wrote:
> The problem is that a document review is what is called, in queuing
theory,
> a large batch transfer...

This is how commercial software development is usually done. Welcome to the
sausage factory. Nobody is going to feed the tech writer incremental bits of
functionality to document over the course of the project. And even if they
do, inspecting an individual component usually doesn't provide the context
you need to write meaningfully about it. If a product is developed only in
big gulps near the end of the project, then that's how documention will be
developed too.

Usually we *are* documenting large batches of components which are arranged
into a meaningful whole as a system. We are documenting the system, not the
increments.

To address the original question about methods of document reviews:

I'd question the underlying assumption that tech writers *need* these
document reviews. I submit that TWs don't really need these reviews - unless
you are relying on them to firm up content you aren't sure about. In that
case you have a different problem to deal with.

Not only that, it isn't your responsibility to make other people do the
reviews. It is very difficult to make people change their behavior against
their will, unless you are their boss. Who needs that headache? Getting
people to do their jobs is a management responsibility - heck, you might say
that is the *only* management responsibility.

Methods of document review:
Put the document out for review, notify the appropriate parties, and then
forget about it - go work on something else. If they are supposed to review
it and they don't, let their bosses hold them accountable, not you. Let it
go... stop obsessing about it.... it's not your fault... :-)

Mike O.