Printed from the Technical Editor's Eyrie,

Editing single-sourced projects

"Single-sourcing" describes situations where one file or database of information contains material that is reused for more than one product or more than one information deliverable. Two common scenarios are:

To complicate a single-sourcing solution, many projects may include both conditions mentioned above: multiple related products, each delivered with more than one information deliverable.

This article does not address the (important) questions of when a single-sourcing methodology is a good solution to an information delivery problem ("good" here meaning saving time and money while maintaining or improving the quality of the resulting deliverables). Instead, I'm looking only at the editor's involvement in the project.

I asked the HATT (Help Authors' Tools and Techniques) group these questions: "How do successful single-sourcing projects handle the editing? At what stage are your editors involved? How do the editors deal with the material -- with all the conditional material in the copy they edit, or with each output deliverable separately (seeing only the subset of stuff that goes into that deliverable), or both, but at different stages of the project? What are the good and bad points of the methods used?"

The answers, as expected, included "We don't have an editor." Other responses confirmed my experience that editing (whether done by an editor, the other writers, or someone else) occurs at these stages:

Few organisations do all three of these editing passes.

Editorial markup may involve PDFs (either writing on printouts or electronically marking up the PDFs), a common scenario in FrameMaker environments; or editors may electronically mark up Word files, help databases, or HTML files. My research suggests that writing on paper is still the most common method used, at least in departments with trained and experienced writers who are responsible for the final output.