Re: Developments in the review cycle

Subject: Re: Developments in the review cycle
From: Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com>
To: "techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Wed, 6 Apr 2016 11:59:40 +0000 (UTC)

Erika awesomely asks...
So my questions are:
1. Do you also see this transformation?
2. If yes, how do you cope with it?
3. Should we manage each chunk separately according to the old model (sounds a bit crazy) or replace the old model with a new one?
I most definitely see this transformation. I'll add that I would describe my workplace as hyper-agile, meaning we take all the increased fluidity of agile while discarding much of the structure. This means that the SMEs are under as much or more pressure as/than the tech pubs team (me). So there's no way I could get full reviews of the full document from the full consort of SMEs. We do DITA, which means topics. The theory is that a topic stands on its own, so review of a single topic (or at least a small set of topics) is meaningful. When a related group of topics is pretty much done, I generate that set of topics as a PDF and send it out to the manager of that team, the QA dept, Support, and other groups that are interested. That's sort of like reviewing a chapter. Near the end of the cycle, I try to generate a full PDF and send it out, but nobody ever reads the whole thing.Â

My DITA is stored in SVN alongside the code, so for each daily build I get my latest changes out to the world as online help. That used to be great until we started using ReviewBoard, and insisting that you get a review before you commit code. Since I'm the only writer, I have to wait for developers to review, and they always put that off. When the lucky day comes and we get another tech writer, we can be more agile... Can commit content changes much more quickly. Then people can see the whole doc set as it develops. Can't wait (are you looking for a job?).
I think strictly following the old model can't work. I think a new model is kind of distilling itself as we speak. It's kind of like Agile, but not necessarily. For me the biggest problem is keeping up with changes. I think some sort of automation can be implemented to track versions of X that we support, maybe other strictly technical values, maybe other things that don't strictly require a tech "author". These should be viable for automatically import into an overall doc set. Identifying who needs to review what, and getting it to him -- that would be great to automate somehow as well. Since the source is "code" and it's in source control, and it can be transformed and transported at will, we should be working along these lines. Who's got the time?
Random thoughts... I hope this thread continues.
Visit TechWhirl for the latest on content technology, content strategy and content development |


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @


Previous by Author: RE: Temp agencies and job boards for local tech writers
Next by Author: Re: Developments in the review cycle
Previous by Thread: Re: Developments in the review cycle
Next by Thread: LinkedIn - Facebook for Professionals? or is it really "Myspace"

What this post helpful? Share it with friends and colleagues:

Sponsored Ads