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.
best practices for internal repository of published docs?
Subject:best practices for internal repository of published docs? From:Sam TechWriter <samtechwriter -at- yahoo -dot- com> To:techwr-l <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Wed, 11 Jul 2007 09:55:45 -0700 (PDT)
I'm looking for best practices for storing published documents so our company employees can find them.
Our current practice depends extensively on file shares, with backup copies in source control. Many of our releases contain many products; A-Z 2.0 could contain ABC, EFG, and XYZ (in this example HIJ and other products do not require updates for compatibility with 2.0). The final CDs combine software with documentation. If I want to update the XYZ 2.0 User Guide for the next CD build, I "drill down" through the 2.0 directory to find the XYZ folder, then copy the document there (overwriting any previous copy). When the A-Z CD is built (using scripts that point to the XYZ folder I put my document in), a copy of the build is placed in a separate directory.
The result: Two directories, one containing the most recent "drop" from the documentation group and another containing copies of all CD builds. When we reach GA (general availability), that build is labeled "GA." Anyone in our company can easily locate the released CD contents, which include the published documents.
This practice assumes that we'll never update the published documents, that every document is strictly related to a particular product, and that all documents are intended for the same audience. Recently we've created documents that defy these assumptions. Now we need to figure out where to put them. Internal folks wouldn't know how to find updated or multiple-product docs (such as an A-Z 2.0 doc) or docs intended for a limited audience - even worse, they might not even know they are available. Now that we've begun updating documents that are already on the CD (which cannot be changed), and producing documents that aren't strictly related to one product, I'm guessing that the-powers-that-be should roll out a new directory structure that doesn't carry these problematic assumptions.
Would you agree?
Remember - this question is limited to the internal repository. See my other message about getting the updated docs to the customer.
Thanks in advance!
"Sam TechWriter"
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-