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: Bugs and changes record keeping From:Sandy Harris <sharris -at- dkl -dot- com> To:TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 09 Dec 1999 11:19:45 -0500
"Cascio, Justin" wrote:
>
> I don't think that's off topic at all!
>
> I've worked in two different software shops, and in each, the help
> development "nice to haves" and bugs went into the same incident report
> system as the program bugs and such.
Probably the best one-page document I ever did was a form for problem
reports. Our group built a software tool used in various places around
a large organisation. Requests for change/fix/enhancement came in from
a dozen other groups. They could mark priority 1 to 5. Priorities they
chose were useless. 70% 1, 25% 2, 5% other. Our manager wanted useful
priority input from users, so I re-defined the numbers:
Please assign a priority to this task.
5 do when convenient
(e.g. next time we are working on that module)
4 put on our schedule
Section manager's signature required
He/she can justify this to:
3 may delay other work himself/herself
for your section
2 may delay work for other section managers
other sections
1 Shut the system down top management
until bug is fixed.
