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.
Subject:Re: Request for change From:Kent Newton <KentN -at- METRIX-INC -dot- COM> Date:Wed, 7 Feb 1996 15:26:00 PST
Eric and List,
You are the list owner and, I presume, the person who originated the list
in the first place. You would know the issues you originally wanted to
discuss on the list. I agree there are very important issues to discuss,
those issues that keep us awake at night. But the other issues, the
little issues, are important as well; they, too, make up a portion of our
jobs. I agree too much time has been spent on whether the 21st century
begins in 2000 or 2001, or when to use "which" or "that," or what "k" or
"K" stands for, or whether to use passive or active voice. Anyone can
look up these answers in a number of good reference materials. But
still, discussing them (to a limited extent) helps people get to know
each other and trust each other when those big issues are discussed.
Some big issues have been discussed on the list in the two weeks since
I'be subscribed to it: whether it is possible to combine both user and
training materials in one document, how best to convert paper manuals to
an electronic format and how to distribute them after they are converted,
how to implement documentation control, and so on. This is the first
we've read about your upcoming project (which sounds like a killer, to
me). I'm sure the members on the list would love to discuss this, if you
would give us the particulars.
I think there are two reasons why these big issues are not discussed as
much as the smaller ones.
First, these kinds of issues are often time-critical and time-consuming.
When we are thrust into the situation like the one you mentioned, we are
too busy trying to complete the project to spend a lot of time on-line
discussing the particulars. We have to roll up our sleeves and get to
work. (If you had had the time, I'm sure you would have asked for our
imput on your project before now.) Only after it is over do we have the
luxury to discuss what we've done, which is too late for the current
project. It does, however, prepare other users for similar projects. It
also helps us to analyze what we did, to disect what was successful and
what was not.
Second, after two or three weeks involved in a difficult project, we'd
rather take a break from it and dabble with the smaller issues, the
issues that do not put such a drain on us, the niggling little day-to-day
In short, I agree that there are critical topics we could discuss, which
I think we do to a degree. I also think, however, that there is a place
for discussing the smaller issues that also make up the daily life of a
technical writer (though, maybe not to the extent we have on some recent
topics). I have found the list helpful for my looming big issue
(converting to electronic documentation to be distributed on CD-ROM) and
entertaining and diverting on some of the smaller issues.
Senior Technical Writer
kentn -at- metrix-inc -dot- com
PS, If you'd care to go into a little more detail about your current
project, I'm sure you'll get feedback from the list. Some of it may even
be helpful! I may not contribute, since I have no experience in crossing
documentation and training yet (especially in such a tight time-frame) --
but there is talk about our department taking over the creation of the
training materials, so I'll read the thread avidly.
On Wednesday, February 07, 1996 12:10 PM, Eric J Ray wrote:
>I'd like to make a request.
>I'd like to see discussions and questions on bigger issues
>than ones that we can look up in a dictionary or reliable
>reference material. I'm sitting here, looking at TECHWR-L subject
>lines of "state names," "online vs. on-line," "commas and
>lawnmowers," and "restrictive vs. non-restrictive banter
>continues." Frankly, none of those issues are what I'd
>consider central to my job as a technical writer. You
>pick a reference source, stay consistant, and realize that
>someone will find fault with it. Oh, well.
>What I'd like to see more of and what I feel TECHWR-L
>is uniquely suited for is discussion of those issues
>and problems that wake you up in the middle of the night.
>The issues you argue vehemently with your colleagues about
>for hours, only to find you've switched sides.
>For example, I'm writing this note while breaking from a
>documentation/training project. My colleague and I are
>collecting information across internal "party lines," if
>you will. We're preparing training documentation about
>what's changing in a known (not by us) but undocumented system. This
>project is absolutely mission-critical to the company.
>The signoff parties are NOT our users. The SMEs can't
>see the forest for the trees (more than usual). We've
>got people telling us to MAKE THOSE OTHER PEOPLE UNDERSTAND.
>I'll get to report back to the VP about our success next week, after
>the pilot class. We started this project last week. In three
>weeks, we'll have trained 1000 people (stand up, in person)
>and we'll be done.
>Ask me if I woke up in a cold sweat worrying about if I
>used "which" or "that" in a specific section. No, I woke
>up worrying about how to deliver what our users need,
>not what the SMEs think the users want, without inciting
>complaints about unresponsiveness. I woke up wondering
>if I'd completely missed the point, or if it really was
>simpler than it had looked. I woke up wondering if technical
>feasibility would line up with business requirements before
>the pilot class. I argued for 15 minutes this morning
>about the difference between using "correct" terminology,
>using what our users expect, or using what they'll need to
>learn. I worry about completing the training and having the
>whole system change. I worry about completing the training
>and discovering that we've overlooked something fundamental.
>THOSE are issues. What _ARE_, in our collective opinions,
>the issues of the profession? If they're grammar or
>notation, I'm switching professions. To paraphrase John
>Brinegar, the profession is about helping people do what
>they need to do. Notational discussions are for reference books.
>Comments and criticism of this note, on or off line, would
>ejray -at- galstar -dot- com
>Eric J. Ray | Eric -dot- Ray -at- wcom -dot- com
>WorldCom, Inc. | W: 918-590-4140
>1 Williams Center 29-5 | F: 918-590-2372
>Tulsa, Oklahoma 74172 | P: 918-690-1314