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:FW: Keeping track of software changes From:Katherin Stanzler <kstanzler -at- BROOKSOFT -dot- COM> Date:Tue, 3 Nov 1998 15:26:31 -0500
Kathy Stanzler
Technical Writer
Brooktrout Technology Inc.
Southborough, MA
(508) 786-9182
kstanzler -at- brooksoft -dot- com <mailto:kstanzler -at- brooksoft -dot- com>
-----Original Message-----
From: Mila Bongco [mailto:mbongco -at- pre-print -dot- com]
<mailto:[mailto:mbongco -at- pre-print -dot- com]>
Sent: Tuesday, November 03, 1998 3:13 PM
To: 'kstanzler -at- BROOKSOFT -dot- COM'
Subject: Keeping track of software changes
Hi Kathy:
Regarding your mail:
<snip>
We have a problem where developers make changes to the GUI without notifying
Doc, and we find out after chapters have gone out for review that the screen
shots are wrong. How do you make sure Doc gets notified of ALL changes to
the GUI? Is there a system or a software product that ensures that this
information isn't lost?
<snip>
I helped set up the documentation department in our company. One thing we
fought for is to have a standard procedure in place where everyone is
informed about changes to each system in development, not only to the GUI
but functions as well, and the reasons for these changes.
Now, for each product (project), we have a librarian/compiler who receives
all the source codes from the developers and compiles these into a new
version. Depending on the product or delivery schedules, compilation takes
place once/twice a week, even daily. The librarian is then responsible for
informing (via e-mail) all the members of that project whenever a new
*version* is available. Always included in the e-mail is a list of changes,
new *features* or functions (with corresponding Specification or User
Requirement numbers), defect fixes (with corresponding defect log numbers),
and so on.
The list can be an attachment, or the librarian can point you to a folder in
your server. The items in the list come from the various developers who are
checking in new or revised code. Each time they check in something, they
provide an outline of the changes they've made and the reasons for these
changes (bug fixes, new *feature*, approved user requirement, etc.) The
librarian collects all these, and pass it on to the documentation and
testing teams for each new version. If you have a testing department, each
new *version* can also come with a list of the status of the bug fixes or
reported errors that the testing lead can compile. This will help your
documentation team a lot, not only for GUI changes, but for changes to how
the system functions as well.
All the best,
Mila Bongco
(you can post this to the techwhrlr list if you like - I could not do a
straight reply because my mail system locked up when I tried to do that from
your posting).
