Concurrent writing and revision

[Tom Campbell <tcampbell -at- WEATHER -dot- COM>]

Interesting to read everybody's comments on this topic.

When I went back to Nancy Hitchcox's original post to see how this all got started, I saw that my down-thread reply wandered from her intent.  She asked about "editors who allow authors to work in a document throughout the publication process."  That's very different from the situation I described, where we had 2 people doing the formatting, corrections, & revisions *for* the users.  (Also, we were doing more traditional publications, not documenting software or, usually, technical systems, either.)

In a more recent job, I used Word to track revisions by multiple authors.  We also used PVCS for version control.  Different colors of revision marks for each reviewer in Word helped, but it was still confusing at times.  We let reviewers choose whether to edit with revision marks themselves, insert electronic comments, or mark changes on paper.  It worked OK, except of course we had to salvage some mangled prose, fix problems caused by people who didn't know how to use Word styles & other formatting features, and correct style inconsistencies.

Now on to Mark Barker's comments...
Mark points out, rightly, that we have to be flexible enough to change our process if it's contributing to a migraine culture.

Well, that would have been nice in the situation I described, if I'd been able to convince management to hire more people to work in our area (after 5 years I gave up trying)--or if we'd been able to have users edit their work after they'd seen the initial format.  But our authors composed text on dumb terminals attached to a mainframe (this was in the mid-1980s).  So after the text came into our system, it was ours until it went to the printer.  

We were as flexible as we could be.  Believe me, when I say we tried to limit users to 2 revisions, we were happy to settle for 4 or 5.  We had one 12-page newsletter that went through more than 30 revisions!  And I'm talking about author's changes, not our errors.  Obviously nobody in their right mind would condone that much "flexibility" in a situation where two people are working on anywhere from 10 to 20 different jobs at a time in a company of 150 employees.

All this is probably moot anyway, since centralized desktop publishing (as opposed to technical communication) operations like the one I described are probably obsolete.  As Mark points out, "content management tools" are the way to go if constant changes are the norm.  

Geoff Hart succinctly states what I was trying to get at: "What I object to is institutionalizing a culture of 'let's not even try to get it right the first five times'. Reasonable revisions, yes; revisions because they can't bother to make an effort, no."

But I especially like Sharon Burton's closing paragraph:
"The difference is fundamentally the value the company places on the documentation. If the company values the abilities of the tech pubs people, the process will occur in a rational and planned manner with the same level of professional reviews that the software gets, even in a rapid application development process. If the company values the docs, they will force everyone involved to value the docs and hold to project plans and review cycles. If the company thinks of the tech pubs people as overpaid typists, the process is insane. Planning is for nothing, reviews are haphazard, and the tech pubs people are publicly blamed for any delays in the release cycle."

Nicely put.

Tom Campbell