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: Release Note problem From:Elizabeth Ross <beth -at- vcubed -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 14 Dec 2000 12:08:51 -0500
On 12/14/00 8:08 AM, Jackie Gishkin wrote:
> I have just started a job as a technical writer in France without having
> any real prior experience. My first project is to write Release Notes
> for the latest build for our "internal software". The problem is that
> the Builds are changing everyday. Recently, I have started to write
> about a new feature only to find out that it had completely changed 2
> days later. I now have to go back and delete what I wrote. I was told
> that I will be printing out the Release Notes once we come across a
> really "good" Build.
>
> Also, instead of having a few Release Notes floating around for the same
> Version, is there a way to compile them together into one coherent
> document?
>
> Since I am in a start-up, there haven't been any established ways for
> doing technical documentation.
>
> Do any of you have some advice to give me? I would apprciate it.
Okay Jackie, you are in a spot.
>From my understanding of release notes, they need to be tied to the build.
Build 1.55 goes with Note 1.55 and the note details the deltas from the
previous build. It should be wordy, just a point-form summary.
Once your company has that really "good" build (read "not enough bugs to
hold it back anymore"), then take your notes document and distill the point
forms into a *new* document that will be released with the build.
I literally cringed in my seat and winced when you said you write things and
then delete them when the product changes. Icky. Bad. Road to Heck. Here be
dragons. <shudder>
I *always* keep such information--it's important to you as the TW and can be
critical in helping determine things like "build 14 fixed issues 2 and 24
but reintroduced issue 10, which appeared in build 5 and was resolved in
build 7."
And that can me the difference between a successful start-up and a
non-successful one.
Good luck!
--
Elizabeth Ross
Senior Technical Writer, V3 Semiconductor Corp.
mailto: beth -at- vcubed -dot- com http://www.vcubed.com
Cogito cogito ergo cogito sum.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Take XML and Tech Writing courses online! Our instructor-led courses
(4-6 hrs/wk) give you "hands on" experience at your convenience. STC members
get 20% off! http://www.online-learning.com/index.html.
---
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.
