RE: Re; Validating documentation

[SIANNON -at- VISUS -dot- JNJ -dot- com]

I think this thread is starting to get a bit sidetracked, as happens often 
here on topics about which we have strong opinions.  Due to the high count 
of 'veteran' tech writers on this list, we are prone to disable discussion 
of a problem by writing it off as the fault of "bad/immature business 
practices".  This is usually because the veterans have seen it all before, 
and are familiar with the archetype, and both the issues and solutions that 
come with it. Newbies, on the other hand, may not be as familiar, and may 
not have the choice of avoiding the context of an employer's bad/immature 
business practice.
     We still need to address the question: how do we deal with the 
validation of docs within our own context, and how would we deal with the 
validation of docs in potentially less favorable contexts? The same 
strategies may not work in different contexts.
     Ignoring the question because the company hasn't reached a particular 
maturity level, or because a few individuals contributing to the problem 
haven't reached a particular maturity level, doesn't help those folks stuck 
dealing with it right now.  It is as much "blaming someone else" as blaming 
reticent SMEs, and serves no constructive purpose besides possibly 
identifying vectors for problems so that they may be included as factors in 
evaluating possible solutions.

     Now, sometimes, it *is* the business practice that may need to be 
modified. Some companies still don't have SMEs _ever_ review their 
documentation (no doc review process seems to be more common in situations 
where the software is being developed for internal use, not for sale to a 
third party). Some companies are still determining their documentation 
needs (which offers a TW a chance to determine review practices, as I 
believe was what prompted the original post). Some have had to deal with so 
much change in a short period of time that the "standard" process gets lost 
in the shuffle of reacting (e.g., with projects that change leadership 
several times). Some have independent QA and testing teams, while some do 
not (e.g., all testing is performed by the developers, or perhaps the tech 
writer for the team). Some test from use cases, some test from the 
requirements, some opt for another route entirely.

     I, personally, have little to offer in the way of solutions right now 
because I am still working on such context-originated issues myself. I 
figured it wouldn't hurt, however, to try to bring us back to the question 
since we seem to have strayed off in the direction of the "content 
ownership" holy war again.

I look forward to hearing more preferred tactics,
Shauna

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at
http://www.ehelp.com/techwr

  Check out the TECHWR-L Site redesign! 
  http://www.raycomm.com/techwhirl/

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