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: True insignificance... and release notes From:Steven Brown <stevenabrown -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 6 Mar 2002 13:42:38 -0800 (PST)
In June of last year we hired a full-time release
manager, who coordinates and schedules "builds" to
move efficiently from our Development environment to
QA to Staging and finally to Production. I've injected
my "deliverable" (i.e., release notes) into her
process.
When Development creates a "build" of our software,
they pull a lot of raw data from a bug and enhancement
database into a Word document that they call "release
notes." As is usually the case with material written
by developers and QA analysts, it can be very crude
and thin.
When a build moves into our QA environment, I'm on a
deployment notification list. My task then is to
review Development's release notes and to prepare a
set of "draft release notes" that will eventually be
distributed to the company. That requires several
tasks:
- Talking to developers to clear anything up.
- Determining if each bug is worthy of "public"
release notes. Some bugs and their fixes are so
obscure that it's not worth the clutter. (For example,
a graphic that doesn't appear properly on the UI.)
- Adding additional information to an item if
warranted.
- Grouping large numbers of bug fixes in a logical
manner.
- Explaining complex concepts for a non-technical
audience. (For example, I had to explain server-side
caching for people who may not understand the
difference between an application server and a web
server.)
My release notes evolve as the build moves closer to
Production, based on technical and end-user reviews
and last-minute changes to the application.
My challenge is distribution. We don't have an
intranet, so I post the release notes to a Lotus Notes
database so that everyone can use them as they see
fit.
My relative success is due in large part to a
well-documented build process. If those folks didn't
create that initial Word doc, I'd have a lot of grunt
work to do.
Hope this helps. Great topic!
Steven Brown
Senior Technical Writer
__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check it out! Get some cool freebies when you buy RoboHelp! You'll receive
SnagIt screen capture software and a 10% discount voucher for RoboHelp
Consulting. This special offers expires March 29, 2002.
www.ehelp.com/techwr
---
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.