TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Malkia Payton Jackson wonders: <<I'd like some feedback on the typical
length of time hard copy reviews of documentation are kept and how are they
stored? I have acquired in a relatively short amount a time, a great deal
of paper (our reviews are handwritten) and I'm not sure how long to keep it
around. I was under the impression that review comments should be kept as a
means of "proving" whether or not information was implemented into the final
product.>>
You can't come up with a good answer to this question until you understand
why you want to keep these reviews in the first place. Given your use of the
phase "I was under the impression", I'd suggest that this part of your
question has not yet been defined. Let me give you three examples (one
facetious, two practical) to show how different goals lead to different
solutions.
Goal: To assign blame and administer punishment to whoever missed an
incorrect technical detail.
Approach: Store the documents in a nitrogen atmosphere (to prevent decay)
within a hidden vault until the first customer is maimed by the software.
When you find out why this happened, use the records to figure out which
employees to feed to the sharks because of their incompetence.
Goal: To track revisions to the documentation so you'll know which
developers are most likely to make last-minute changes.
Approach: Store the documents until after the product ships, then use the
final round of revisions to identify which programmers were revising things
right up to the last minute. When the next version of the software begins
development, start working with these developers early to minimize the
amount of last-minute rework must be done.
Goal: To implement a program of continuous improvement. (A less facetious
version of the first goal.)
Approach: For each writer, identify the kinds of problems the editor
repeatedly had to fix. Spend some time working with the writer to teach them
to avoid these problems. As a result, the writer works faster (fewer
revisions required) and the editor spends less time fixing preventable
problems.
See the basic point? Identify the problem you're trying to solve, then use
the solution to that problem to define whether or how long to store the
revised documents.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
---
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.
