|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2023 --> Collaborative editing
Vous êtes ici : Essais --> 2023 --> Collaborative editing
By Geoffrey Hart, Fellow, STC
Previously published as: Hart, G. 2023. Collaborative editing: editors as the author’s helpmate. ISTC Communicator, Summer 2023: 15-17.
As a freelance editor, most of my work these days is done alone, in a private home office. But editing is an inherently collaborative activity, and back in the day, when I worked in-house, I collaborated directly and at great length with the authors I was teamed with. Now that I’m happily self-employed, I don’t think I’d ever go back to such work, but I do miss the in-person collaboration. Working with authors to learn their message and help them craft it was an ongoing delight and is still a pleasure after 35 years of this work.
I’m no longer in the same room as the authors, and I’ll never meet most of them in person, but we still collaborate. This collaboration is more awkward, however, as most of them are located in China or Japan (thus on the other side of the world), so finding a mutually convenient time to discuss their manuscripts is difficult, and the problem is exacerbated by the language differences: most of the authors speak fluent technical English, but are far less comfortable with conversational English. Although I know enough Chinese and Japanese to be polite, I can’t communicate effectively in either language. This creates a sometimes uncomfortable distance between myself and them.
In this article, however, I’ll focus on the kinds of editorial collaboration I was part of in the early days of my career, when I worked as the in-house editor for a Canadian government research institute and then for a consulting forestry engineering research institute. If you’re in that kind of in-house environment and have the pleasure of working directly with the authors, there are several ways you can be more mutually collaborative. If you’re working with authors who share your language and your time zone, much of what I’ll describe can be easily adapted to online collaboration (eg Zoom meetings). Although I’ll focus on the editorial perspective, it won’t take much effort to see how most of what I’m going to describe is applicable for pairs of writers who work collaboratively or for authors who work with subject-matter experts. My own experience can be generalized to a surprisingly wide range of situations. It may even help you mitigate some of the negative impacts of the distance imposed by online work.
Once upon a time, my employer embarked on a kaizen process-improvement exercise with the goal of streamlining our peer review and publication process (Hart 2011). One of the key innovations was that before an author began to write any report, we held a meeting that brought together representatives of the key stakeholders (authors, managers, and the communication group) to work out the details. The theory, which proved to work very well in practice, was that by achieving consensus before someone began writing and before we embarked upon the review, we could eliminate the most serious problems and many lesser problems right from the start and long before we asked peer reviewers to look at the manuscript. More details on the review process we developed, which built on some of my proposals before the kaizen exercise got underway, can be found in Hart (2006a).
The stakeholders present at the planning meeting played complementary roles: the author proposed the publication; their manager approved the request to create a publication and defined how it fitted within their overall research program; the research director then put the manuscript into the larger context of our overall communication and knowledge-transfer program, but also acted as a management representative; and my boss or I contributed our expertise in audience analysis and document planning. At the meeting, we discussed the overall and specific goals of the report, the best approach to meeting those goals, the logical flow of the manuscript (that is, we created an early outline or revised one submitted by the author), and rigorously defined the deliverables. Writing didn’t begin until we’d achieved consensus on what to write, how to write it, and how to distribute it. We recorded these details in a summary document that authors and reviewers could consult while they worked. Subsequently, I worked with the author to determine how to meet those goals. Some authors required more handholding, others required less.
Templates were a key part of our collaborative process.
Most organizations develop a series of relatively standardized document types that their authors will write. All documents in a given category have a series of recurring elements that must be included, and they must meet specific criteria for how those elements should be created and what information they should contain. For example, manuscripts intended for managers typically began with an Executive Summary, whereas scientific reports began with an Abstract. Both of my former employers produced several ongoing series of reports for our different audiences, as well as a variety of research reports that would be published in international peer-reviewed journals that had their own content and style requirements.
To capture the recurring elements in each type of manuscript, I designed a series of word processor templates whose contents would make it easier for authors to produce the best possible information before they sent it to me for editing. These included all of the required headings and other boilerplate text for a given report series, so the authors didn’t need to type that text and I didn’t need to edit it. But more importantly, I included explanations of what information must appear in each section. For example, the text that described the contents of the Executive Summary asked authors to start by defining the problem they set out to study, explain why it was important, and describe the methods they used to gather and analyze data that would solve the problem. (Ideally, this information was created during the planning meeting and entered directly into the author’s document, which was based on the relevant template. But the approach was flexible enough to accommodate special circumstances.)
The templates also contained clickable links to various useful resources like our house style guide and a summary of the planning meeting that I described in the previous section in case the author forgot what they’d committed to write. The planning meeting documents also helped the reviewers to understand the goals and content of a manuscript so they could determine in their review whether the manuscript met those goals and contained all the specified content.
I called these templates “dynamic style guides” (Hart 2000) because they integrated tightly with how the authors worked and could be used interactively as the authors wrote their paper to help structure their writing. But what made them truly effective was that I helped the weaker writers flesh out the initial outline into something that more strongly supported their writing. Specifically, I interviewed the authors by asking questions whose answers filled in the details.
Because most of the people I worked with were engineers and scientific researchers, not professional writers, many of them struggled with their writing. The biggest problem was often not knowing how to start. Before we developed the new planning process, authors often did brain dumps that didn’t follow a clear logical order and that omitted important information, while including considerable redundant information readers didn’t need to see. This created unnecessary editing challenges. Even the good writers often wrote more than they needed to, in an ineffective order. We solved this problem in two ways.
First, we taught them how to create outlines, both the preliminary outline I described above and something that supported the writing process far more effectively (Hart 2006b). Outlining is rarely taught well in school, since most teachers think of it from the structural perspective of document sections such as the Executive Summary and the Conclusion. The result was an outline that looked identical for every manuscript and was therefore ineffective as a support for writing. An effective outline goes far beyond that skeleton. In the context of our evolving writing and review process, templates already contained more specific descriptions of what needed to be said. Compare the two following writing cues:
Traditional outline: “In the Executive Summary, I will summarize the key things that I studied.” (Yes, real-world authors who struggle with writing really do write things like that.)
Improved outline, included in the template: “In the Executive summary, I will describe the problem we set out to solve, followed by what we already know and what we don’t know about the problem. I will then report what we did, present the results of the research that provide new knowledge, and discuss the implications.
Better, but still not perfect. In the second step, I sat down with the author and interviewed them so they could replace that still-generic outline (which could apply to any report, not their specific report) with an outline that provided the essential details that distinguished the author’s report from all other reports. For authors who typed slowly and inaccurately, I did the typing for them while they dictated their answers to my questions, thereby saving both of us considerable time. When I asked a question, I didn’t permit generalities for answers; the author had to concisely and specifically state what they planned to write, even if some of the details still needed to be filled in. When the author had difficulty articulating what they wanted to say, I provided prompts and asked pointed questions that would let us replace the more general points with actual details. I then summarized these for the author, echoing back what they’d told me, thereby ensuring that I’d understood their responses to my questions. Once we agreed on those details, I typed the final wording into the draft manuscript. For example, working from the skeleton of the writing, I asked questions such as the following for the Executive Summary:
What is the problem you tried to solve? “We still don’t know the full impact of mechanized harvesting of trees on forest sites.”
How did you study that problem? “We used a single-grip harvester paired with a wheeled forwarder to harvest a site and extract the wood to roadside, then measured the damage to the vegetation and soil.”
What did you find? “This system produced less damage than a previously studied full-tree system that paired a feller-buncher with a grapple skidder to extract the trees.”
What are the implications? “The company we worked with should switch their operations to the single-grip harvester plus forwarder system.”
Much better, although you might not grasp the subtleties of the jargon!
This revised approach to creating an outline produced much more effective outlines (Hart, G. 2006b). Note that the answers to the interview questions, though not the final words the author needed to say, basically comprise a finished report: they contain almost all the key information the reader really needs to know and nothing the reader doesn’t need. All that’s missing are the details, such as where the study was conducted (for example, the type of forest), the specific models of harvesting equipment, and whether or not the workers met the site protection guidelines defined for the operation.
The work I’ve described thus far provided a rigorous and effective way to determine what the author needed to describe for our standard reports. Because the authors and I were familiar with the nature of the reports that we routinely produced, this approach was good enough for most of our needs. But every so often, we needed to create something new and different. For example, when a team of our researchers produced a datalogger (a device that automatically records data generated by working machines such as tree harvesters and timber trucks), we needed documentation for that product. My audience analysis revealed that there were two very different audiences: the machine operators who needed to start and stop the data recording and troubleshoot problems in the field, and the managers back at the field office who programmed the dataloggers to record specific types of data at a specific frequency.
Because this type of documentation was completely new to us, none of our existing templates met our needs. So I resorted to a traditional tool that deepened my audience analysis: the “five W’s” approach used by journalists (Hart 1996, 2002). By asking a series of questions, I was able to determine the information that had to go into the manuals for the two audiences. For example:
What tasks must the operators perform? Start and stop the recorder. Troubleshoot problems based on the indicator lights.
Who performed the tasks? Machine operators and (sometimes) their managers. People working in a bilingual (English/French) environment.
Why did they perform these tasks? To provide managers back at the office with the data they needed to manage the timber harvesting operation. (This suggested a list of additional tasks, some for the machine operators and others for the managers.)
When did they perform the tasks? For the managers, before the dataloggers were installed on forestry machines and after machine operators returned the data to the office; for the operators, each time they performed an action such as seizing a tree and cutting it off at the base.
Where did they perform the tasks? For the managers, either in the field (using a portable computer) or in the office (using a desktop computer); for the machine operators, in the cab of their machine.
Based on these and other questions, we determined that two user manuals were required: one for programming the devices and extracting their data, plus a much simpler one for using the devices to collect data. Since the work that the operators performed in the field often involved dirty, wet, noisy conditions, we determined that a classic printed manual wouldn’t work, and given the nature of a machine’s onboard computers and the fact that the datalogger had no display screen, online help could not work for the machine operators. (Note that the work I’m describing was conducted more than 20 years ago. Modern technology would have provided alternatives such as a large display that permitted the use of embedded online help.) So instead, we developed laminated quick-reference cards that focused on visual instructions, with minimal text. The lamination protected the instructions, and the resulting reference cards were small enough to fit in the limited physical space that was available in the machine’s cab. And by and large, the resulting user guides were successful and only required minor modifications, mostly to account for evolution of the datalogger itself.
This approach helped ensure that the authors provided all the necessary information that the two groups of users needed. But because we carefully reviewed all our publications before releasing them to their audience, I also needed to work with the author to review my edits and review comments from peer reviewers.
Here, I’ll focus on reviewing my edits, but we followed a similar process for dealing with comments from peer reviewers. Most of my editing involved fairly obvious changes, such as correcting subject–verb disagreements, typos, and grammatical infelicities. These kinds of edits didn’t require much discussion. Indeed, for things like changing formatting to agree with our standard style, the author had no say in the matter, so I usually just made those changes without using revision tracking. Why ask them to review changes they weren’t allowed to reject? To be sure that this approach was appropriate, we discussed it with the research director and our authors until we agreed on a consensus approach that everyone could live with. We agreed that the authors would simply accept any alterations that were correct without further discussion.
However, we also agreed that if any of my changes appeared to be wrong, the author needed to discuss the problem with me rather than simply rejecting the change. (Authors also worked with peer reviewers, when necessary, to review their comments and critiques.) The logic was simple: If I misunderstood the original wording, some of our readers were also likely to misunderstand. For these errors and for any questions I had about the author’s draft manuscript whose answers would guide my other revisions, I phoned the author or visited them at their office. If they were working in the forest, I arranged a time to sit down with them when they returned, discuss the problem, and work together to develop a solution. With the edited manuscript displayed on my computer or on the author’s computer, we discussed my questions and the author’s answers until we determined what changes were necessary, then made those changes. Authors who were fast typists often made the corrections themselves; slower typists were happy to have me do the corrections.
Apart from the pleasures of working directly with people rather than exclusively with their manuscripts, the approaches I’ve described significantly improved the quality of our reports. That’s not just my biased opinion; when we surveyed our readers about the quality of our publications and asked them for suggestions to improve the quality, most were highly satisfied and we received few requests for changes.
The approaches I’ve described in this article should inspire you to look for similar ways to collaborate with your own authors. If they inspire innovations I haven’t discussed, why not write them up and share them with others? That’s a different, but also satisfying way for writers to collaborate.
Hart, G. 1996. The five W's: an old tool for the new task of audience analysis. Technical Communication 43(2):139–145.
Hart, G. 2000. The style guide is dead: long live the dynamic style guide! Intercom, March:12–17.
Hart, G. 2002. The five W's of online help for tech writers.<http://techwhirl.com/columns/the-five-ws-of-online-help/>
Hart, G. 2006a. Designing an effective review process. Intercom July/August 2006:18–21. https://geoff-hart.com/articles/2006/reviews.htm
Hart, G. 2006b. Effective outlining: designing workable blueprints for writing. Intercom September/October 2006:18–19.
Hart, G. 2011. Uprooting entrenched processes: process improvement using the kaizen method. <http://techwhirl.com/articles/technical-communication-process-improvement-kaizen-method/>©2004–2024 Geoffrey Hart. All rights reserved.