Standard Doc Review Cycle-Online/Print Help (take II)

[Geoff Hart]

Gurpreet Singh provided additional information: <<I work in Electronic 
Test and Measurement industry.>>

In that case, I suspect that IEEE (www.ieee.org) will have a SIG that 
can provide information on this if nobody on techwr-l has a good 
recommendation. In fact, some of your engineers or developers probably 
already belong to an appropriate SIG and can introduce you to its 
members and resources.

<<I'm concentrating not on the writing part but on the review process; 
like peer review, technical review et al. Do we have a formal process 
for this?>>

Again, I'm not aware of any broad standards. In fact, that's why I 
wrote my article. My goal was more to propose a toolkit for 
constructing your own process.

<<In addition, is 'document review cycle' industry dependent?>>

Yes, but only in the narrow sense that some industries may have 
specific legal and other requirements that must be met. In that case, 
you may need to add a specific review phase related to those 
requirements.

In regards to your Web search for methodologies, you said: <<Most of 
the listed processes are good but impossible to follow, partly because 
reviewers have very limited time and we can't ask for more than our 
share. Unfortunately, that share is very less as well and which is why 
I want to create a process so that this time is used effectively.>>

Have a look at my bibliography 
(http://www.geoff-hart.com/resources/bibliography.html), and skim 
through the titles or search for the keyword "review". There are 
several other articles there that discuss (sometimes satirically) the 
obstacles to reviews and how to overcome those obstacles.

<<I thought to start with the standard processes first, and then keep 
fine tuning those processes to fit my needs.>>

Except that there are no standard processes, that's a good choice. 
Processes do eventually become somewhat sclerotic, and need to be 
reinvigorated. Plus, as times and circumstances change, processes 
gradually diverge from reality and must change to accomodate them 
(http://www.geoff-hart.com/resources/2005/living.htm).

<<I really liked the doc freeze idea. I wonder if it is 100% effective 
in my organization.>>

"Freezes" of any type, from documentation to software design, are 
always possible and effective. But they must have strong support 
throughout the organization. Unfortunately, there's a pernicious flaw 
in the mindset of modern managers that tells them the goal of 
development is to keep adding and refining features right up until the 
product ships. This is clearly nonsense, but it's become the new gospel 
for managers. That doesn't mean that _we_ should accept it without a 
fight.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart   ghart at videotron.ca
(try geoffhart at mac.com if you don't get a reply)
www.geoff-hart.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -