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.
It's an on-going minor debate here. Our current solution is to provide
release notes (more detailed than readme files) for only those bugs which
were reported by clients. Saves us from having to write descriptions of
three times as many, since we tend to find most of them ourselves. (We have
a stellar QA department, and I work directly with them, product support and
development. Some days it's so cool to go to work!)
If you don't have client-reported bug fixes, then I'd suggest you step back
and see if there is a way to categorize the bugs, first by function, then by
some general area (such as calculations, UI/navigation/focus problems,
database problems, etc.). This is more than just a priority/severity
assignment. Sometimes, people have essentially reported the same bug, but
have described it differently because they found it in a slightly different
place in the software.
The challenge comes in figuring out which things are related to each other,
so you only have to write it once. One more good reason for you to
understand as much as you can about your product!
Good luck.
Connie Giordano
-----Original Message-----
From: Gilda Spitz [mailto:gspitz -at- longview -dot- com]
Sent: Monday, August 20, 2001 4:37 PM
To: TECHWR-L
Subject: Readme files with references to fixed bugs
In addition to books and online help, our Documentation group also
provides readme/release note files.
Up to now, those files have been very simple txt files, describing the
various components of the software, providing contact information, and
so on. If there's a major change since the last release, we mention it,
but we don't provide details.
I have now been asked to provide much more detail on each release.
Apparently some of our users want a bug-by-bug description for each
minor release, so that they can decide whether to upgrade or not. (It's
a complex enterprise-wide product, so they don't necessarily want to
upgrade every time.)
This is my opportunity to change the format from txt to something with
hypertext links - either Acrobat or HTML. And I'm delighted with that.
But I'm struggling to find a way to provide the bug list.
We have an internal database in which we log bugs (er....issues). There
are sometimes hundreds of issues logged per release, and some of them
are just typo fixes, etc. It would be difficult to decide which fixes
are important enough to be listed, and I really don't think we want to
list them all.
I've been looking at readme files from all sorts of other software, to
get ideas, and that has helped. But I need more input.
Has anyone out there had a similar problem? I'd love to hear your
solution. Thanks in advance.
Gilda Spitz
Manager, Documentation
Longview Solutions Inc.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
---
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.
