Monthly Archives: September 2007

General Impressions: “In Praise of Editors”

Last month, on, Gary Kamiya wrote a very interesting article titled “Let us now praise editors,” which you can read here: link). Janice Gelb sent this article to our discussion list, quoting a few passages from it, and I was surprised that we did not start any discussions around it.

As I finished the article, I was left with a series of questions that I thought we might enjoy discussing. Please feel free to write a comment here to our blog, but please also subscribe to our discussion list, and see what gets going over there.

Here are the questions that this article raised for me:

  • Are editors less confident than writers? Kamiya said that “a good editor needs to be as self-confident as a writer” (mainly because we are dealing in a subjective realm of trying to improve the writing for the reader).
  • Is writing harder than editing? Kamiya said that writing is very creative, whereas editing is reactive. Initially, I agreed with that statement, but upon reflection I’m not so sure.
  • Are editors an endangered species, especially with online and Internet publishing? I’d like to think that those writers, those businesses, those publishers who value high quality writing for their readers will not allow us to go the way of the dodo bird. Kamiya stated: “The art of editing is running against the cultural tide. We are in an age of volume; editing is about refinement. It’s about getting deeper into a piece, its ideas, its structure, its language.” This was one of the few places in the article that Kamiya acknowledged that editing is more than just grammar and style, but it was appropriately located.

Kamiya ends his article by truly singing the praises of editors and suggests, “Someone is noticing. Someone is reading. Someone cares.” I sure hope he is right. What do you think? Is someone noticing?

Excerpts from STC Annual Conference Report

Kelly Schrank

[Note: I wrote a very detailed 14-page conference report for my employer. I then abstracted that report and published a 5-page article in Newsbrief(external link), the Mid-South Chapter’s newsletter. What appears here is a belated collection of highlights from that newsletter article.]
The Technical Communication Summit, STC’s 54th Annual Conference, was held May 12–16, 2007, in Minneapolis, Minnesota. Around 1,400 people attended the annual STC conference this year.


My first session was “Estimating and Tracking Project Costs for Financial Success” with Joyce E. Lasecke. I thought this was a good session, very structured with good handouts that make it easy to go back through later and re-learn the concepts. Her presentation had two distinct parts: how to estimate and how to track. She very methodically began the part on how to estimate by outlining the three ingredients to a project estimate: (1) metrics, (2) assumptions, and (3) risk assessments. She then defined those and showed how to use them to your advantage. She went over the case study provided, which seemed to me to be a good example of a project estimate. The part on tracking was also good, with insights for how to start and what to do when you get off track. A good session, especially if project management is part of your job.

My second session was “Effective Page Layout for the Non-Artist” with Jean-Luc Doumont. Jean-Luc was an excellent presenter, very organized and very entertaining. He believes that page layout is about revealing the structure of the document visually. Unlike some people who think that a pretty layout and fancy graphics will bring the reader’s attention to the text, he believes that people will pay attention to the graphics and ignore the text. He also characterized a page as having two dimensions: vertical and horizontal. He believes documents need much more white space than most people allow. He likes big top margins and big left margins. “Space is a luxury.” This is where it became obvious to me that his ideas on design could be a bit “creative” for most technical communicators. His examples are full of white space and seem (to me) to be much more the work of marketing than documentation though I liked the look of them. All in all, an informative and fun session with lots of takeaway ideas.


My fourth session was “If I’d Known Then What I Know Now – Lessons Learned and Best Practices.” This was a lively and informative panel of speakers. Each discussed a lesson learned in their career and a trend in the technical communication industry. One of the funniest things to come out of this panel (from Bobo Vatovec): “The most common language in the world is Bad English”. A lot of their lessons learned and trend advice was tough to swallow: technical editors being told to lower their level of quality, tech writers being told to spread their wings and move away from our tech pubs departments? But these are experienced technical communicators doing a variety of different things in the industry for big companies and their own companies, so we should at least listen to what they have to say…

My fifth session was “Copymarking, Clarity, and More: Progressions of STC’s Technical Editing Community.” I went to three different tables to learn about three different topics:

  1. The first was “Growing and Managing a Formal Editing Process” with Lisa Adair. Lisa is a technical editor for Rockwell Automation, a company that is revamping their whole tech pubs process. Their new system is topic-oriented, not publication-oriented; writers own a section of information, as opposed to documents. Their formal editing process began with a task force that worked on updating the company style guide. They began by picking a secondary style guide, and put topics in the company style guide where the editors veered from the secondary style guide or where the secondary style guide didn’t address something specific to their company. Another instrumental part of their formal editing process was to establish the levels of edit and create an editor’s checklist. The metrics they created in the level of edits document allow them to quantify their job. This was an interesting session for those in big companies that may have many editors, but it emphasized to me the need for an editor’s checklist and to be estimating my work.
  2. The second was “Make Every Technical Editing Minute Count” with Jackie Eldridge. Jackie is a very experienced editor who put together a thorough and helpful handout for this progression. To understand the project, she suggested you first find out the purpose of the document from the author. Make sure the introduction material covers this, and that steps are in a logical sequence to that end. To understand the author’s expectation of you, she suggested that you use your editing checklist as a menu: talk to the author about which of these are most important to them. Advantages to knowing the author include being able to look for their trouble spots and fixing those so they do not embarrass them. Generic editing advice included: looking for the three “in”s: inconsistencies, inaccuracies, and incompleteness; making sure there is a source for information presented; and using different colors for different types of edits. I found this session helpful in not only proving what I already know to be correct, but also in offering some different ways of thinking about the process.
  3. The third was “Concision and Clarity” with Susan Ledford. Susan is a technical writer and editor with experience in localization issues. She offered four reasons to pursue word reduction: (1) decreases costs, (2) increases readability, (3) increases usability, and (4) supports re-usability and single sourcing. In localization, word reduction is a directly measurable reduction in costs, as those excess words don’t have to be translated. For publications that are printed, shorter documents cost less to print. In addition, there is less to maintain when you reduce documentation length. In single-sourcing situations, the difference is exponential. From a usability standpoint, if there is less to read, readers are more likely to read it. She advises to do the following: (1) Use the search function to help you delete worthless words, (2) Create checklists of the type of words to commonly reduce, and (3) Rephrase sentences and paragraphs and reduce them to “content chunks.”

My eighth session was “Out of the Solitudes: Progressions of STC’s Lone Writer Community.” I went to three different tables to learn and talk about three different topics:

  1. The first was “Preserving Sanity as a Lone Writer” with Dana F. Utz. The sole writer in his department for the last 8 years, Dana believes you should impose structure on your work through a “styles and standards guide.” He also suggests acting as if you are a part of a department in how you approach your work by documenting your tasks in a policies and procedures guide and tracking project time and milestones. He had a very nice handout of the presentation.
  2. The second was “Editing Your Own Work” with Jerry D. Franklin. As a freelance high-tech marketing copywriter, Jerry must edit his own work on a regular basis. He offers six suggestions for editing your own work: (1) Take time away from the project to gain your objectivity (distance), (2) Put on your proofreader persona, (3) Use other style guides, (4) Create a style guide and document templates in advance, (5) Get non-SME reviewers on your team (customer service, tech support, marketing), (6) See if you can get a student to proof for the experience.
  3. The third was “No Longer Alone” with Christopher Thiessen. Chris was an engaging speaker, very much interested in our own experiences and having us share them. He offered advice for people with specific questions and concerns. Like many of the other editing speakers, he suggested creating a style guide to ease the transition from working alone to working with others, and he suggested creating a list of commonly used words and their preferred usage.



The conference materials are available on the website(external link). They are organized by presenter, so if you want the materials for any of the sessions I described, you should have an easy time finding them.

Editorial Ethics: The Role of the Editor Before Peer Review

Geoff Hart

Editors who work with authors before a manuscript is sent for review face certain challenges. Since we’re often the first to see a manuscript, we sometimes encounter problems we must help solve before they come back to bite the author.

These problems fall into a variety of categories, of which I see three repeatedly in my work:

  • Content
  • Logic
  • Plagiarism

In this article, I’ll discuss the nature of these problems, provide examples from my own career as a science editor, and suggest how similar problems might arise in other types of editing. I’ll conclude with some thoughts on how to confront the problems in an efficient, positive manner.

Problems with the content

Over the years, I’ve found that the more editing work I do, the more poorly designed scientific studies I discover. Once the science is complete, often after several years of fieldwork, there’s nothing much that can be done about the problems with the study. Instead, I have to deal with the consequences: something that may appear unpublishable, at least at first glance, because of seemingly fatal flaws in the experimental design. The equivalent in other branches of technical communication might be working with beginner authors or with professionals such as engineers for whom writing is a distant last in their list of priorities—or skills. The situation may be compounded by tight deadlines that prevent the authors from going back and fixing things.

As an editor, I can’t solve these problems, and in some cases, it’s doubtful whether I have the expertise to justify trying. What I can do is try to ensure that the flaws are not hidden and to suggest coping strategies that might mitigate the flaws. For example, I routinely advise authors that it’s wise to be open and honest about flaws in their study rather than trying to conceal those flaws. The peer reviewers chosen by science journals are generally every bit as smart as the author; indeed, they’re specially chosen for their expertise in a subject, and for their willingness to pounce on the slightest flaw in a paper. Many also look carefully for any appearance of unethical behavior, and will pounce even harder on authors who are trying to conceal a serious flaw or claim better results than their data justify. An author who, despite my advice, insists on concealing flaws in their research, inevitably ends up wasting several months waiting for the results of the peer review, the reviewer will force them to do what I told them to do in the first place and resubmit the manuscript for another round of review, hoping that the changes will now be acceptable to the reviewer. Why not save those months by stating up front that the research needs to be confirmed with additional data and specifying any flaws that must be addressed and resolved through future research? All scientists understand and accept the fact that it’s sometimes necessary to discover better ways to do research by screwing up an initial study.

Similar situations arise in other forms of technical communication. Take, for example, the autonumbering feature in Microsoft Word, which is broadly known to have stopped working more than 10 years ago. Microsoft’s refusal to fix this buggy feature is understandable; the bug is rooted so deeply in the plumbing of Word that trying to fix it might destabilize other, more important features of the software, which is something Microsoft simply can’t afford to do. An even more serious problem lies in the Master Document feature, which can actually cause serious file corruption and data loss ( link)) — unlike the autonumbering bug, which causes only frustration and wasted time. Refusing to acknowledge these problems is one thing. But retaining the features both in the software and in the user documentation is unethical. Well-known solutions exist to both bugs, using nothing more than the features already present in Word. That being the case, why not recommend using these solutions instead of solutions that don’t work? That would be a more ethical way to proceed. Unfortunately, this example illustrates the problem faced by many editors: we lack the power to do anything more than raise a problem and propose a solution, and very few of us have the luxury of being able to resign and go elsewhere if that solution is not accepted.

Problems with logic

Every so often, we find ourselves in the happy situation of knowing more than our author, and having a chance to save an author from looking foolish. One paper I edited by an eminent Asian scientist proposed a perfectly plausible explanation for the author’s experimental results. There was just one small problem: the author had neglected a simpler explanation that was every bit as logical, and failing to at least mention that alternative explanation would have humiliated the author before an audience of their peers. (This knowledge was the kind of thing any graduate student should have been aware of, and that any peer reviewer would leap upon as an explanation. I’ve been deliberately vague here in describing the problem because I would hate for the author in question to come across this article.) It took me nearly half an hour to frame an explanation of the problem in such a way as to spare the author loss of face, and it was a great pleasure in subsequent years to see the author including my explanation in his other papers.

In scientific publishing, it’s the responsibility of journal reviewers to reject bad science or faulty logic, so when I’m right and an author still ignores my advice, I can usually be confident they’ll receive similar advice from someone (i.e., the journal) with the authority to force them to take the comment seriously. I can satisfy my ethical responsibilities by raising the problem, explaining its consequences, and doing my best to persuade the author to deal with it honestly and well; I know that if I don’t succeed, someone else will do the job for me. (“Giving up” would be less ethically acceptable when you’re the last person who will see the manuscript before it is published, but as in my previous example, sometimes we have no choice but to accept that we can’t change the situation.) In other branches of technical communication, we may lack this kind of built-in quality control process, and it becomes a considerably more serious problem. If we know a product is unusable or potentially even dangerous, and we cannot persuade its developers to fix the problem, the problem may appear only once the product hits the market—at which point the real world has its say: purchasers reject the project, leading to potentially large lost sales, or possibly someone is injured and the lawyers get involved, leading to potentially large punitive fines. In such cases, ethics force us to at least consider going around a recalcitrant author or developer and making our case to their manager. Sometimes we may even need to ask ourselves whether we should leak a problem to the press to ensure that action is taken before a problem arises, not after.

Potential plagiarism

Most of us encounter a greater or lesser degree of plagiarism at some point in our careers. That’s particularly true if we work with authors for whom English is a second language, since they may lack the skill to create fluent English sentences by themselves and thus have a greater incentive to simply copy someone else’s wording. Other authors, including those for whom English is a first language, simply don’t understand copyright, and believe that it’s acceptable to create an entire document out of other people’s sentences so long as they attribute the source of the text. In most cases, it’s not; at a minimum, direct quotations should appear between paired quotation marks, and an entire manuscript filled with thickets of quotation marks would, at best, look unusual. In each case, we must be alert to the potential problems that may arise—ranging from simple embarrassment to serious legal consequences.

In one particularly memorable case, an author I was working for decided to try publishing essentially identical papers in two journals. (This is often referred to as self-plagiarism.) Journals, predictably, aren’t fond of this practice because it deprives them of unique content when another journal publishes the same paper; it’s also seen as a sly and inappropriate way to pad the list of publications in one’s résumé. When I recognized what was happening, I informed the author of the problem, and explained that whether or not he agreed with my take on the ethics of the situation, it was an unwise trick to play; he was writing in a specialized field where the odds were high that the same peer reviewers would be chosen by both journals. The author ignored my advice, and sure enough, was caught. Both papers were rejected. In addition, one journal warned the author that all future articles he submitted would be carefully screened.

In fields such as science, much of the discourse is built upon citing other people’s studies and comparing one’s own results with those studies. This is standard practice and covered under the doctrine of fair use. So long as an author attributes the original author’s words or data by citing the source, they’re generally following the letter of the law and the standard practice of their discipline. In such cases, we can often reach a compromise in which we modify some of the original wording (as is expected in our role as editor) to create a paraphrase of the original words and ensure that the source is cited. This allows the author to keep their words, satisfy ethics by acknowledging the source of the words, and avoid potential legal entanglements.

Depending on the nature of the job, it’s not necessarily our formal responsibility (as part of our job description or a contract signed with a client) to go looking for such problems. But even if it isn’t, it’s our responsibility to inform the author of such problems when we find them. Finding them often isn’t all that hard. For example, when working with many of my foreign authors, quoted text often stands out clearly from its surroundings because it has an entirely different voice from the rest of the paper and uses words that (based on the word use in the rest of the manuscript) I wouldn’t expect the author to have in their vocabulary. Given the number of papers currently available online, particularly as “pre-publication” versions that authors post on their own Web sites before they sign over copyright to a publisher, a quick Google of the suspicious phrase often turns up its source.

Often, we cannot force the author to do anything about this, and often we can find ourselves in deep waters if we try too hard. A few years ago, a friend nearly got herself fired when she reported that a senior manager at her company had plagiarized something in a way that was almost certain to lead to legal action against the company; by raising the issue and pursuing it in a highly ethical manner, she saved her employer from a significant problem, but in so doing, stepped on some powerful and unforgiving toes.

Breaking the bad news diplomatically

As editors, we rarely have the authority to force an author to fix a problem, and even when we do, “force” is rarely the right solution. Instead, it’s better to work with the author in such a way that we’re seen as an ally, not an obstacle. As illustrated in my examples (ignoring a field of inquiry in a literature review, an inadequate study design, plagiarism), the solution often lies in explaining the problem in such a way that its importance and the consequences are clear to the author, then providing suggestions that help the author solve the problem. If we make our solution sufficiently easy to accept, then it’s easier for authors to accept the solution than it is to fight us over the issue. In the case of plagiarism, wording such as the following might suffice:

“While I was researching concept to ensure that I understood what you were saying, I noticed that this complete sentence was taken, without modification, from reference. Although this practice is borderline acceptable if you cite the original source, it is considered plagiarism by many publishers, and may cause you serious trouble during the review process. For example, there is a significant risk that the author of the paper you are quoting will be one of the peer reviewers selected by the journal, and when they recognize their own words, they are likely to ask the journal to reject your paper and possibly even reject future papers that you submit. My advice is to rewrite the sentence as follows proposed new wording, rewrite it in your own words, or place the entire sentence in quotation marks; whichever solution you choose, you must provide a literature citation that defines the source of the text. Reviewers like to see their own work quoted, and are more likely to accept your manuscript if you do so.”

The goal is to carefully raise the issue, always with an emphasis on helping the author avoid trouble. Sometimes, you can’t succeed, as in the case of self-plagiarism that I described. In that case, it may be acceptable to allow the standard quality control process to solve the problem for you; in my example, the journal’s peer review process filled that need, but in the workplace, a quiet word to one of the managers or others who will sign off on a review can at least focus their attention on the problem. In other cases, the solution requires us to understand what factors will make the author take our advice seriously.

For most of us, it’s easy to believe that the consequences of such ethical questions are small potatoes in the larger scheme of things, and to pass responsibility for solving the problems to someone else. The temptation to do so is even stronger when we’re under deadline pressure or when we fear that we’ll get ourselves in trouble by making too much noise. Unfortunately, this abdication of our responsibility sometimes leads to very serious consequences indeed. The loss of the space shuttle Challenger and death of all its crew ( link)) illustrates the consequences of a failure to make the necessary effort. The Challenger disaster had many causes, and there have been many detailed examinations of the causes of the disaster. I’m not an authority on the consensus opinion of all these studies, however I recently came across an intriguing explanation that hasn’t been explored perhaps as deeply as it should have been. In this case, the author challenged the conventional explanation that the engineers did not clearly explain the risk of launching the shuttle, instead proposing that the managers who made the decision were governed by economic considerations (they needed a successful launch to demonstrate the reliability of their rocket engines and secure additional contracts). Is this true? Possibly. But I find it hard to believe that any manager could have ignored a recommendation in which the consequences were clear:

“We all believe that if you launch the shuttle, you are likely to kill all its astronauts. The technical reasons for this are spelled out in Appendix 1. That’s bad enough, but you will also set back manned space exploration for many months, if not years [the actual delay was nearly 3 years], and will do irreparable damage to our company’s reputation, ensuring the loss of the contracts you hope to gain by launching the shuttle tomorrow despite our warnings. In this context, we are confident that delaying the launch by 1 to 2 additional days will be a minor problem, and we recommend that the launch be delayed.”

As in the case of my friend who nearly lost her job for blowing the whistle on plagiarism, this wording would not have gained the engineers any friends, but it would have saved several lives and protected the company against considerable lost income too, thus soothing some of the sting of the painfully direct wording.

If you’re lucky, most ethical problems that you face as an editor will be far less severe. But as I’ve illustrated in this article, it’s unwise (not to mention unethical) to simply assume someone else will spot and fix ethical problems for us.