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: More on drafts -- From:dmbrown -at- brown-inc -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 23 Sep 2002 16:40:21 -0700
"Smith, Martin" wrote:
>
> One thing to keep in mind in this ongoing drafts debate is that software
> engineers are often accustomed to checking their work into a revision
> control system on a daily basis. Thus, their daily progress is always
> accessible to the entire team. This policy ensures that the code is always
> in a buildable state.
Not at all. Programmers and writers alike have to choose: check in daily, or check in when ready to show.
If something takes longer than a day to write, whether it's code or text, you can't check it in every day without having it be partly unworking.
The programmers I work with keep files "checked out" for days, if that's what it takes to complete the task. When they're ready--typically, when they've confirmed that the code will build--they'll check files in.
I've also worked in organizations where everybody checked in everything, every day. It was understood that lots of stuff wouldn't work: code wouldn't always compile, docs wouldn't always be very presentable. The value was that the revision control server was backed up every night, and the least amount of work would be lost if one or more individuals' computers went down.
Both systems have value--but each organization has to choose. You can't have it both ways.
>
> The notion that you can't see my work until I'm completely finished does not
> fit within a software engineering paradigm. Even if the project just got
> underway, the code will usually still run--most of the features won't be
> implemented yet, but it will still run.
>
> As writers we can fit in better if we follow this paradigm.
Personally, I'd rather check in a book every night for back-up, even if it's full of TBDs, notes, reminders, snippets of "draft" text, and so on. If the organization requires only complete docs and working code be checked in, then the programmers and I are going to be individually responsible for back-ups (which means they won't all get done) and the code and docs definitely won't be checked in every day.
HTML Indexer 4 is still the easiest way to create and maintain indexes
for web sites, intranets, HTML Help, JavaHelp, and other HTML documents.
Now with fully integrated cross-references, target frames and windows,
multiple-file output, "one-step accept" of default entries, and more!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Experience RoboHelp X3! This new RoboHelp release combines single sourcing,
print-quality documentation, conditional text and much more, into the most
monumental release of RoboHelp ever! http://www.ehelp.com/techwr-l
Enhance, optimize and automate your FrameMaker-to-PDF workflow with TimeSavers:
Define all PDF features in your source FrameMaker files ONCE, distill MANY.
Bookmark Controller, Link Controller, UnBloat & more : http://www.microtype.com
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
