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.
Kevin McLauchlan wrote:
>snip<
The developers record *everything* in their database, so there is no
searchable/filterable distinction between formal "bugs" in released
software, and glitches, suggestions, explorations, afterthoughts, etc. that
go along with the in-house development process.
>snip<
This is an organizational problem, not a documentation one. The tool we use
is set up so that, before an issue is added to the database, it must be
categorized as a Problem, a Request for a change or a Requirement to be
analyzed for new releases or new products. It must also have a Severity
level. Severity levels drive the allocation of resources. Every issue must
also be identified with its Product and the module within the product.
All of the above should be configurable in any good issues tracking program.
In addition, our process requires that new issues must be reviewed by an
acceptance board before the responsible parties work on them. This board
includes developers, management, a representative of the testing department
and (on some products) the documentation guy.
That may sound like a lot of bureaucratic process, but we learned the hard
way that it saves a lot of time and grief.
