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.
Hi,
in our documentation team, we are also starting to use StarTeam, but I have
no experience with it until now.
Another thing is, that documentation is included into quality assurance
procedures.
We have four different levels of bugs, the lowest is "d". Documentation
issues are mostly c and d.
For some clients, we give detailed reports about all changes of contents in
documentation, (exceptions are spelling or grammar errors.)
One reason is, the documentation will be translated to other languages.
There spelling errors usually disappear, but contents must be changed,
without translating the whole text again.
These are also included into (internal and external) test procedures.
The error levels help us to decide priorities.
And it is much better to fix bugs reported by test team than by clients.
The problem to track the changes lies in the complexity. The documentation
reached now a length of almost 2000 pages.
Fortunately, we are working now with specifications, in earlier times, the
documentation was used as a kind of specification.
But: The program was changed, so we had to change the documentation, and
often we had to guess how the program should be working.
Now we are doing only changes for signed of specs, either by clients or by
research and development.
Higher quality of documentation.
Documentation is (almost) ready together with the program.
Free Saturdays and Sundays.
