A bit of clearing up on final reviews?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Sierra Godfrey is improving her review process, but keeps <<...sticking on
what to do when the two engineers here say, like they did last time, that
they want to see the pre-print version themselves to ensure it's okay?>>

If at all possible (politically and practically) refuse them that right. If
they've done their job correctly and professionally, there should be no
further changes required, and they should rely on you to do your job
correctly. That means that you've reviewed all review comments, incorporated
them if they were necessary, and discussed them with the reviewer if you had
any doubt whatsoever about why the comment was made. It also means that if
one reviewer wrote "high" and the other wrote "low", you didn't merely write
"in between" as a compromise; instead, you got the two of them together,
found out why they disagreed, and reached a consensus (or went to a higher
authority to make a judgment call). If you don't do these things, then it's
appropriate to let the reviewers have another look to confirm that you
haven't neglected making an important change simply because you didn't
understand why they asked for the change. Plus, we're all human, and that
means we miss things occasionally, so having a second set of eyes look
things over rarely hurts.

<<I'm the only writer here so having someone else check the final final
version is helpful--but if it's these two, then they feel free to start
making all sorts of little changes again, as if it were in review.>>

Ask them my favorite parental question: "Which part of 'final' review did
you not understand?" <g> I guess the question comes down to whether they're
still finding important things to change at this point. If they are, then
something's wrong with the previous review, and you need to find out what it
was and fix it. (I recently threatened one programmer with amputation of one
finger each time he changed a screenshot. As of today's build, it looks like
I need to get out the axe and pay him a visit. <g>) If they're just playing
word games, there's no reason whatsoever to accept their changes. You're the
word geek, and if they want to waste their time splitting synonyms, let
them; just don't feel obliged to give in to their suggestions. (But do feel
obliged to accept good suggestions.)

<<If the answer is to not let them see it, who should?>>

Who is competent to ensure that the reviewers have done an adequate job?
That's the person who should review the review commments and determine which
ones need to be worked on and which ones can be ignored. You can be the
language expert, but some _technical_ expert must be present to make
judgment calls on technical issues. If that expert happens to be one or both
of your two problem reviewers, then you'll have to grit your teeth and let
them have one more kick at the cat. But if they keep finding significant
things to change that they missed during the first three reviews, you really
need to talk to their manager and discover a way for them to do the job
right the first time. Amputatig fingers, though drastic, might just work...
after all, they only need two fingers to type, right? <g>

<<Is it right to trust one person with the absolute final version?>>

It may not be "right", but it's often the way things get done. The
alternative is having several different signoffs at the end of the project.
Here, after a researcher approves a document for page layout, we have final
approvals by the research director (technical content), the division manager
(political and technical content), and Head Office (political content). The
author gets one last look after all these signoffs, but that's it.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer