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.
Has anyone had experiences good or bad with the numbering of documents on
a large project? There is talk going around above me that we are going
to come up with a numbering scheme for the project's myriad documents. I
presume that this will include using the document numbers in 8.3
filenames. At first blush, I don't like this idea.
For one, I don't try to pressure developers and other authors to keep
track of minor issues such formatting and revision numbers. Besides the
fact that most probably would not keep up with such things if I did
insist on it, it is my opinion that they should not have to. I can
reformat a fifty page document from top to bottom in well under half an
hour, and people who don't live in Word like I do would lose valuable
time away from writing code messing with document formatting. By the
same logic, I don't help them write their code. I can't imagine asking
them to learn a non-intuitive, non-mnemonic numbering scheme for naming
and finding documents. They'd have to cross-reference some list just to
look up the latest database definitions. I do agree that standardization
is positive, when used appropriately, but I think that a simple,
English-based naming system, in combination with simple version
numbering, would be much better. xxxxDSGN.DOC for specs, xxxxUTP.DOC for
unit test plans, xxxxOM.VSD for object models--that sort of thing.
Am I missing something here? Inisight is appreciated.