RE: Address this. . .

["McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>]

Marguerite Krupp sagely observed:
> 
> Bill Swallow wrote:
> > IMHO, release notes should focus on what IS in the release 
> and not on
> > what isn't.
> 
> Yabbut...
> 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. 


 - Kevin




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- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info. 

Please move off-topic discussions to the Chat list, at:
http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat