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.
I think Barry's right to look at the percentage of
users that will encounter the bug. If it's buried
six levels down in an infrequent task, it might not
need to be documented. Determining which features
are "seldom used" can be tricky, though.
Another issue is the severity of the bug. If you're
talking about an error message that says "Sorry,
can't gerplunk your whoziss" that's one thing -
corrupting the database or causing a program to
crash w/o warning is something else.
"Three shall be the number of thy counting, and
the number of thy counting shall be three. Four
shalt thou not count; neither shalt thou count two,
unless thou proceedest directly to three..."
BSOD being right out. :-)
An earlier poster mentioned telling the user to
enter today's date or a future date without a
warning that entering a prior date will cause an
error. That's ok in my book, as long as the error
is trapped and doesn't cause any data loss.
Those are the bugs that _require_ fixes.
Dan
Dan Hall
Sr. Technical Writer
SchlumbergerSema RTEMS
-----Original Message-----
From: bounce-techwr-l-72045 -at- lists -dot- raycomm -dot- com
[mailto:bounce-techwr-l-72045 -at- lists -dot- raycomm -dot- com]On Behalf Of Kieffer,
Barry
Sent: Wednesday, May 01, 2002 11:45 AM
To: TECHWR-L
Subject: RE: Documenting a buggy feature
Sometimes as tech writers we see ourselves as the truth police, sometimes to
a detriment. There are plenty of bugs that I have documented due to an
over-zealous developer's demands that might have been best left
undocumented. If only 0.5% of users might even encounter a certain bug, why
draw attention away from the task and run the risk of confusing even 1% of
the readers who might never encounter the bug? For the rarest of rare bugs,
that is what technical support is for.
Where do you as a technical writer, and development team member, and
possible stockholder, draw the line?
.barry.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you using Doc-to-Help or ForeHelp? Switch to RoboHelp for Word for $249
or to RoboHelp Office for only $499. Get the PC Magazine five-star rated
Help authoring tool for less! Go to http://www.ehelp.com/techwr
Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com
---
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.
