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 (http://word.mvps.org/FAQs/General/WhyMasterDocsCorrupt.htm(external 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 (http://en.wikipedia.org/wiki/Space_Shuttle_Challenger_Disaster(external 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.

54th Annual Conference — Trip Report for Technical Communication Summit

Michelle Corbin

Hello SIG members! It’s been a week since I returned home from the Technical Communication Summit, and I have recovered from the time away from the office and I wanted to share a few tidbits from the conference.

We attended leadership day on Sunday, and gathered invaluable information that will help us plan our next set of activities. I learned a great definition of leadership from incoming president, Linda Oestreich: “Leadership is the ability to cause others to act in desired ways for the benefit of the organization.” Ultimately, each community leader was encouraged to determine what we wanted to do from year to year, and then just go do it; that is, don’t do everything and don’t do what you think you “should” do, but just do what your members want you to do and do what your volunteers sign up to do. So, Technical Editing SIG members, what do you want us to do? 🙂

We had a very interesting keynote speaker, Simon Singh, who spoke about the making of his documentary about a mathematician solving the proof for an age-old mathematical equation. Although the specifics and details about that mathematical equation did not stick, I did take away two things from listening to his experiences — first, when choosing to edit something, you must consider the audience and context and make sure that it is right, and second, the technical accuracy of your content is critical as you run the risk of losing your audience’s trust.

A very popular session this year (as in past years) was “The Myths and Trends in the Changing English Language.” They talked through several common issues, such as ending a sentence with a preposition, use of the serial comma, and passive voice. As a fellow “word nerd,” this session was a light-hearted treat, where I got to learn what “snarky” meant. My one golden nugget from this session was to be reminded that “goodwill is more important than being right.” As editors, we sometimes need the goodwill more than the rightness of a rule or guideline.

The Technical Editing SIG had its own session of progression table topics — all about editing! Many thanks to our moderator, Diane Feldman, who helped coordinate these topics with the help of you, our SIG members! Each table was full each time, and everyone seemed to really engage in the conversations. Perhaps each presenter might consider summarizing their session in an article for our blog and newsletter!

The closing keynote speaker (yes, we got two keynotes this year) was Ze Frank, who told two great stories about the designs of airline safety cards and about “accelerated anxiety” and the changing landscape of how everyone wants to join the media conversation — the explosion of blogs, MySpace, YouTube, etc. He is a designer at heart, but an excellent communicator through his designs. I laughed out loud frequently and left the conference with a smile on my face.

Although I attended other technical sessions, which I might try to summarize in other posts or articles, I wanted to highlight these above from my experience at the conference. Did you attend the conference? What was your favorite session? Please consider sharing your experiences with our other SIG members!

STC Summit 2007 Report

Virginia Janzig

I attended the STC Summit for the first time in about 10 years. In addition to being a presenter in the Editing Progression, I attended many of the sessions that were offered, and spent worthwhile time in the vendor showcase, especially the bookstore.

Three things stand out to me.

First, the organizers had clearly paid attention to the comments received about prior conferences. The  conference was more focused on writing and editing, and much less on tools. And the variety of different kinds of writing topics was tremendous: everything from processes and procedures and structured language to highly technical online documentation. Having recently taken a job in a courseware development group, an area about which I know very little, I was pleased to find more than one session on instructional design. The two I attended were quite helpful.

The editing progression had several presenters on a wide range of topics, and it was well attended. A couple of other sessions on language were also well attended and useful, as well as entertaining. And our language is nothing if not entertaining.

Second, several sessions on various topics provided information for both beginning and advanced writers. Assessing an audience and its needs is always a challenging task, but I think that the organizers and presenters did an excellent job of delivering to both ends of the spectrum.

Third, I was especially glad to see sessions on careers, not only what kinds of careers are available in the technical documentation arena, but also how to progress in a career: what opportunities to look for, how to build skills, and how to present yourself (not just your resume) in a professional and business-like manner.

The Minneapolis Convention Center was a great venue, and the city had a lot to offer. There were plenty of rooms for all of the sessions (although a few of the most popular were standing room only), and the vendor showcase area had refreshments and Internet access. The incredible walkways made it really easy to get from hotels to the convention center and to lots of other businesses.

In closing, I was pleased to see how many young people attended the conference. Clearly, technical documentation is perceived as a legitimate career and career path, and, if we can help persuade the U.S. Department of Labor to update its definition of this job, then I think that the STC and technical documentation as a whole will benefit, and the technical community will be well served.

Paper, Screen, or Scissors? Editing on Hard Copy or Soft Copy

Tim Slager

The question posted in our discussion list: Should editors edit on hard copy or soft copy? The answer: Yes. Or, it depends. Essentially it is not a matter of should; it is a matter of personal preference and what works best in different situations.
The exchange on the STC Technical Editing SIG discussion list in response to this question went on for several days and included 20 posts, which is higher than average for our moderate-traffic list. Apparently, we tend to be passionate about how we do what we do.

Hard Copy

On one side are those who print a copy and mark it up. Several people mentioned that they notice more errors when they edit hard-copy documents. Hard copy also has these advantages:

  • Easier to flip back and forth to compare for consistency
  • Very portable
  • Easier to see punctuation marks and spelling errors
  • Easier on the eyes
  • Less risk of computer-related stress injury for the editor
  • Easier to mark suggested moves of text
  • Often easier to see corrections in contrasting ink

But the tide is turning, even for those who prefer hard copy. Some people will compromise by marking up hard copy, and then scanning it to make a PDF file. One poster likes to edit hard copy and make changes in soft copy. Another marks up the hard copy and then transcribes comments to soft copy, both for legibility and to tone down “intemperate remarks” (on those rare occasions when one makes it onto paper).

Ultimately, it’s a matter of taste: an “online version of the document is helpful…but I still prefer to deliver markup on hard copy.” One poster still prefers “my trusty red pen.” Another suggests: “Perhaps that is in part due to eyesight issues and in part due to lifelong habits and learning modes.” Some prefer “a quieter, slower paced approach,” and believe it leads to better quality.

Soft Copy

Not everyone wants a slower paced approach, however. When there is a lot of work to be done, speed counts. For some, hard copy may be the preferred approach, but “time and cost considerations” take precedence and “in my current job, I work most often with soft copies.” Several noted that soft copy is faster, and time is money. “Online editing is a cost-saving measure,” said one poster “I can return a document for author review in nearly half the time it takes the other editors.”

The “flipping back and forth” in hard copy can be distracting to some. You might notice structural problems that, in some cases, are better left alone.

The tools that are available with a computer offer a big advantage to online editing. Several people noted that searching for repeated problems is easy with soft copy. One commented, “I’m sure I provide better edits now that I have access to PDF files” for searching. Change tracking tools can be troublesome at times but allow writers to view markups in much the same way they can with hard copy.

Certainly, for many of us soft-copy editing is a big part of our job responsibilities. In fact, later posts in the thread turned mostly to an exchange of advice for how to work with Adobe Acrobat, Word, and other online editing tools as well as with document management and version control software.

One editor took a job on the condition that she could “continue working… completely online.” She goes on to say, “I definitely prefer soft-copy edits, and will do a hard-copy edit only when specifically requested by the author.”

Another noted, “I’ll edit on hard copy if I have to, but I much prefer soft copy at this point.” I sense some ambivalence here, though: was there a change in preference? Someone else perceived that “younger team members do prefer soft copy; it seems they are more comfortable with the technique and it is quicker for them.”

There’s More Than One Way to Do Things

The person who observed the preference of younger editors for soft copy, counters by noting that “many others my age or older might still prefer hard copy.” Different people and different circumstances call for different approaches.

One editor summarizes it like this: “Both types of editing can yield acceptable results. As to preferences, different editors will give you different answers. I might give you a different answer at different times, depending on what I’m doing and how I’m feeling.”

Another says, “I think that both are acceptable….I prefer to edit hard copies when proofreading but I vastly prefer soft copies for comprehensive editing.”

This either-or view seems to characterize the variety in the larger community of editors. No one implies that their approach is the only one.

There seems to be a general, if at times reluctant, sense that the move is toward more online editing. One post states that the choice of software that is used for soft copy editing is pivotal, and that such tools keep improving. It concludes with, “I doubt that there was much serious copy editing going on at PC screens 20 years ago, but ten years from now doing it on paper might also be a relative rarity.”

The first response to the question of which method was better begins with what sounds like a hard-line opinion: “Editing hard copy is best.” But this same post ends with “I edit by reading hard copy and making changes in soft copy. That seems to combine the best of the choices. Hope this opinionated answer helps.”

In the end, it seems to be a split opinion.

General Impressions: “The Technical Editor as Diplomat…”

Michelle Corbin

I recently re-read the journal article “The Technical Editor as Diplomat: Linguistic Strategies for Balancing Clarity and Politeness” by Mackiewicz and Riley (Technical Communication, Volume 50, Number 1, February 2003, pp. 83-94(external link)).

This article discusses 8 different strategies, based on linguistics research, for balancing clarity and politeness when making editing comments, in the hopes of building and enhancing the author-editor relationship. Although I do not agree with all of the strategies and conclusions that the authors make, I did find it a fascinating article – one that made me actually think about and try to articulate my own thoughts on the role that politeness plays when I make my editing comments.

Although this is not a recently published article, I thought it might be nice to use it to kick off this new type of newsletter article in the Technical Editing SIG blog/newsletter. We receive so much information that it is difficult to know what to take the time to read, and the SIG is trying to help you make a decision as to whether to read an article or not – we want to entice and encourage you to read these articles (and who knows, maybe join a conversation about them on the blog or in our discussion list!).

Do you remember reading this article? Did this entice you into reading it (or re-reading it)? Do you have some thoughts about this article? Please consider sharing them on our blog or as part of our discussion list (I decided to cross-post this to both places, in hopes of encouraging cross-reading/cross-participation in our blog and discussion lists. (:biggrin:) ).