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.
> If we all like the linguistic aspects of our jobs (or careers), it's
> a cinch that some people are going to react when a faux pas occurs
> in the Kingdom of Spelling and Grammar. We can all learn not to
> leap with knee-jerk swiftness when we perceive insults to the language;
> yet hasn't each of us breathed a silent "Yes!!" at one time or another
> when someone else did the public editing job?
No Ken, I can't say that I've ever breathed a silent "Yes!!" after
reading a public edit. I feel badly for the writer who was publicly
embarrassed. Why can't we use the same professional courtesy in this
group that we use with our coworkers? When I'm editing a colleague's
document, I don't do it publicly. I meet with the writer one-on-one.
Likewise, if I felt an irresistible urge to edit someone's message, I
would respond to that person directly.
I subscribe to this group to read the debates on technical communication
issues, not for grammar lessons. I really haven't seen that many
grammar nits on this list and like Faith, I think we are making a
mountain out of a mole hill. (pardon the cliche ;-)
However, the few instances of nit picking that did occur
only served to interrupt the flow of ideas and did not add any value
to the dialogue.
-------------------------------
Now I'd like to add a new topic to the fire. I'm interested in finding
out how other writers have made the transition from writing feature-oriented
software documentation to process-oriented documentation. When an
application is extremely complex and there are multiple ways to accomplish
the same task, it can be difficult to work in every feature that
is related to a particular process. Is it our "duty" to use every single
feature that is documented in a reference manual in a corresponding
process-oriented users manual, especially when some of the functionality
is redundant and would cause confusing lateral offshoots in an otherwise
linear and iterative process flow? (redesigning the product is not an option)
Thanks in advance for your input.
Lisa Kaytes
(lisa -at- warren -dot- mentorg -dot- com)
