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.
Marguerite Krupp sagely observed:
> Bill Swallow wrote:
> > IMHO, release notes should focus on what IS in the release
> and not on
> > what isn't.
> Among the things that ARE in the release are the known bugs.
> Call 'em what you will ("Known Anomalies," "Caveats," and
> "Issues" are among my favorites), but they're there. I'm in
> the camp of those who believe that you save yourself, your
> users, and your support staff a lot of grief by simply
> listing the bugs, along with brief descriptions and
> workarounds, if any. No promises that you'll ever look at
> them again (because sometimes you won't), just a simple
> statement of the facts.
> IME, users say that they're more interested in what doesn't
> work than in what got fixed in a release, just so they can
> avoid the known problems. In most places I've worked users
> want to see the open bugs list before the closed bugs list.
> Just $0.02 more. Ultimately, the old "Golden Rule" applies:
> "Whoever has the gold makes the rules."
All true. In my experience, anyway.
However, our practice is to revisit anything that's open,
each time we do a new release, on the chance that:
a) there'll be time/resources to ... ahem... address it to the point of fixing it
b) it might get fixed-or-modified by some other change we are making
c) we can see if it's been escalated by either some big customer pushing harder or by additional customers being affected.
d) it has effectively gone away, and can be closed.
An example of "d" is when we didn't have time or available test
machines to test a release on an old platform.
Basically, the number and intensity of complaints would be
our barometer as to whether that platform had reached the
end of its supportable life for our product(s). If the vast
majority didn't care, then we'd no longer support that ancient
flavor of Windows, or Linux from several kernels back, or
that version of AIX that runs only on a previous century's hardware.
We don't do Mac, but people familiar with the great divide
of Mac "Classic" and OSX would know what I mean, or the
newer divide that is closing off support for non-Intel Macs.
Anyway, the upshot is that we've always meant, by address,
that we'd "see what we could do with the problem". Sometimes,
after doing the cost-benefit or the possible/ain't-gonna
analysis, the "addressing" stops there.
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at: http://www.ModernAnalyst.com
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-