Re: Bugs in Documentation

[Jim Grey <jimgrey -at- IQUEST -dot- NET>]

Ruth Glaser <ruthg -at- GORETEK -dot- COM> wants to know:
>1. How do you define documentation bugs (incorrect information, omissions,
>style inconsistencies, etc.)?

All of the above.  In paper manuals, *in my experience*, those three
categories cover all documentation "bugs."  YMMV.

>2. Do you rank them in order of significance when determining if they'll be
>fixed for the next release?

Yes.  I base my ranking on how deeply NOT fixing the problem will affect the
user.  Generally, errors and omissions far outweigh style breaches.

>3. Do you let known bugs slide when pressed for time?

It depends on the bug.  I fix what I can in the time available, of course.
If a document has a lot of critical bugs and I don't have time to fix them
all, then I lobby for more time.  If I don't get more time, I fix the
critical bugs that will give me the best return (that is, the least amount
of customer frustration and complaint), using the time available.  What
doesn't get fixed gets pushed regretfully to the next release.

>4. Any other thoughts on the subject?

Some bugs *are* show stoppers -- those that can cause harm to the customer,
the customer's data, or the equipment itself.

Peace,
jim
--
jim grey          |beebeebumbleandthestingersmottthehoopleraycharlessingers
jimgrey -at- iquest -dot- net|lonniemackandtwangin'eddiehere'smyringwe'regoingsteadyta
                  |http://www.iquest.net/~jimgrey/

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message:	TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands:	LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe:	LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner:	ejray -at- ionet -dot- net