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.
>This is more than a battle between the perfectionists and the realists. It
>frequently is a battle between management and writers, when management
>understand either the process of creating a document or the value of good
>documentation. And there are always the bean-counters who want to quantify
>everything,and get upset when they can't - and there are always the workers
>who get worried when someone tries to quantify some element of their work
>*can* be quantified.
>And of course, there are those people who think that whatever they can
>quantify has to be how things are evaluated, because to evaluate on
>non-quantifiable things is "non-scientific"
>I once worked for a company that really didn't know how to classify writers.
>We typed, so we were in the same category as secretaries, someone decided,
>so the edict came out that raises etc. would be dependent on the following:
>1) typing speed, measured in sheer words per minute, based on standard typing
>2) the number of pages average that was throuput a writer's hands in a given
>length of time- no matter what the needs of the project, or the nature of
>3) typos - with one mark off per typo, misspelled word, etc, no matter the
>length of the document, time frame, etc. There was a "zero tolerance" for
>typos, even in documents of great length. One typo in a 1-page summary
>counted the same as 1 typo in a 150-page document. An incorrect graphic
>(the wrong screen print for the context, for example) was a typo.
>Gramatical errors were typos. you get the picture.
>I lasted there about 6 months, and quit in disgust. All the wrong things
>being valued, to my way of thinking. This was true company-wide.
>>From: Matthew Stern[SMTP:MAStern -at- PLATSOFT -dot- COM]
>>Sent: Friday, October 25, 1996 1:30 PM
>>To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
>>Subject: Re: acceptable error rates
>>In response to several messages about how many typos it is considered
>>acceptable for a technical publication to have:
>>I never known a company that sought perfection in terms of avoiding
>>typos, misused words, and other minor errors. The main concern is
>>whether the document is technically accurate and readable. If there are
>>errors in the document, well, that's what the review process is for.
>>In general, it hasn't been a problem if one, two, or even a few typos or
>>misspelled words sneak in the final copy. At the time we finish a
>>document, we're more concerned about catching major errors and ensuring
>>that the manual is accurate than finding every minor flaw. Remember the
>>time crunch we normally face at the end of the project. We don't want to
>>hold up product shipment because we demand that our manuals be
>>Typos and writing lapses become a problem is when a writer's sloppiness
>>(both in typos and in accuracy) *consistently* interferes with the
>>documentation process -- such as when it normally takes too long for an
>>editor to mark up that writer's manuals or when significant amounts of
>>inaccurate material written by that writer needs to be corrected at the
>>last minute. This is a qualitative issue based on the writer's ability
>>to work with others and produce acceptable work. Not all of these
>>attributes can be easily quantified.
>>Hope this helps.
>>Sr. Technical Writer
>>Platinum Software Corporation
>>mastern -at- platsoft -dot- com