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-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/ for more resources and info.


Follow-Ups:

Previous by Author: docs on frozen CDs - how to handle updates to docs?
Next by Author: Re: best practices for internal repository of published docs?
Previous by Thread: Re: docs on frozen CDs - how to handle updates to docs?
Next by Thread: Re: best practices for internal repository of published docs?


What this post helpful? Share it with friends and colleagues:


Sponsored Ads