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: Calling a Bug a Bug From:Matthew Horn <mhorn -at- macromedia -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 10 Mar 2003 19:17:51 -0500
>>I am very careful to make our product sound
>>as stable and robust as possible. I never use the term "bug" in any
>>document that will go to a customer.
This particular tack can backfire in certain sectors. Server software springs to mind as an example. If your user is a hard-core developer, then you better use the word "bug" or they will have a hard time figuring out what you "may" mean.
>>And I NEVER include the big long list of bug numbers that have been
>>fixed in a release, e.g., 5122, 5123, 5134, 5145, 5166, 5278, 5982, etc.
We do, for the server products anyway, since often these fixes are logged by large enterprise customers and that is the only way I can think of to communicate which bugs were fixed. How else would a customer who wants to know if bug #45678 was fixed find out?
>>Heavy use of the word "may"
I'd say this is a result of poor QA. If you don't know WHY and WHEN the bug occurs, how could it possibly be fixed?
matt
-----Original Message-----
From: Beth Agnew
To: TECHWR-L
Sent: 3/10/2003 1:32 PM
Subject: Re: Calling a Bug a Bug
I always expect that customers will read release notes (ok, I'm an
optimist!) so when referring to anything in the product that does not
work the way we want it to, I am very careful to make our product sound
as stable and robust as possible. I never use the term "bug" in any
document that will go to a customer. I also avoid words such as defect,
problem, and issue. "Issue" sounds argumentative; "defect", "flaw" or
"imperfection" sounds like someone didn't do their job. If I _must_ use
one of those words, I prefer "problem" because problems have solutions.
Rather than saying "there is a problem with alignment of non-portrait
text" I prefer to say "non-portrait text may not align correctly" and
then give them the workaround if there is one. Heavy use of the word
"may" because some customers may never encounter the problem, even
though it exists.
And I NEVER include the big long list of bug numbers that have been
fixed in a release, e.g., 5122, 5123, 5134, 5145, 5166, 5278, 5982, etc.
Order RoboHelp Office X3 by March 14 and receive a $100 mail-in rebate,
plus FREE WebHelp Merge Module and FREE iMarkup Software, for a
total giveaway value of $439! Order today at http://www.ehelp.com/techwr-l
Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday 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.
