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: Is it just me? S/W doc question From:"Parks, Beverly" <ParksB -at- EMH1 -dot- HQISEC -dot- ARMY -dot- MIL> Date:Thu, 29 May 1997 07:59:09 -0700
>Melissa Hunter-Kilmer wrote:
>> When you're documenting an application, and it changes, is there
>> a procedure in place to notify all concerned? Or do you just
>> find out after you've written the chapter, and then you have to
>> rewrite it?
Becky replied:
>>>Working closely with the development team is very important, and I wish you
>success in your efforts to convince management of this fact. But even when
>you
>work as an integral part of the team, there still may be changes that you
>aren't aware of. One way to make sure you know about all changes is to use
>the
>configuration management tool that the developers use. The developers here
>use
>ClearCase and our build manager set it up so that whenever a developer checks
>in a change, I get an email notification that includes the file changed and
>the developer's check-in comments. I get a lot of email messages, especially
>late in the development cycle, but it usually only takes a few seconds to
>determine whether the change affects documentation.<<
=====
What a wonderful setup, Becky!
I guess I'm in a somewhat unique position in that I'm both documenter
and developer. Every morning when I come in, I do a "get" on all the
source code (using Visual SourceSafe). The modules that have changed
since the previous day are listed seperately. That helps. Then I do a
full compile on the code, so each day I am working with the absolute
latest changes; therefore, the version I am documenting is never more
than a few hours behind the changes.
And the *really* great part about wearing two hats
(developer/documenter) is that when I see something screwy, I can just
FIX IT. I don't have to present my case to other developers who probably
could care less about the misspelled word on the screen or the command
button that is out of place or labeled inconsistently with the rest of
the program.
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html