Chapter 6

Revising with Others

In his final interview, Thomas describes his views on suggesting improvements to his teammates’ writing:

Thomas: Unless it’s really bad, I don’t think it’s really my place to tell other people what to do. I mean, they’re smart people. If it’s good enough, I’m not going to criticize it.

Eduardo likewise describes a “hands-off” attitude toward other teammates’ writing:

Eduardo: I thought she should have worded that section less strongly. It’s not how I would have put it. But she’s the one in charge of writing that information, so she can write whatever she wants.

Lily explains how such a “hands-off” attitude eventually caused resentment on her team:

Lily: I remember being so frustrated when Elsa did the whole thing. And she didn’t get it. She was like “Well, it’s just a rough draft if you want to edit it.” And I was like “What’s the point? You already did it.”

Thomas’s, Eduardo’s, and Lily’s comments illustrate how uncomfortable students can feel when suggesting changes to a teammate’s work. Sometimes, the reluctance is due to feelings of ownership — that the person who wrote a section has the right to phrase and organize things the way he or she wants. Sometimes, as Lily suggests, revision seems pointless if the group can simply agree to move forward with what has already been done. At other times, students hesitate to suggest revisions because they fear hurting a teammate’s feelings through criticism, or they worry about seeming egotistical, as if they are better than their teammates.

These concerns about revising or critiquing others’ work are understandable, but a well-functioning team should be able to overcome this reluctance. Generating a first-rate project involves recognizing that the team owns the work it produces and that every member shares a responsibility to make every part of the project the best it can be. Learning how to revise and critique your teammates’ work is an important part of this process — as is learning how to take and use the feedback your teammates provide on your own work.

This chapter presents some strategies for building a strong revision process into your team’s culture. When team members feel comfortable critiquing and revising one another’s work, the team will draw on everyone’s strengths and insights and will produce a superior product. Developing a strong revision process and a team culture in which constructive critique is welcomed and encouraged will allow your team to focus on what is best for the project without worrying about hurt feelings or who “owns” a particular section of the project.

Developing a Culture in Which Constructive Feedback Is Encouraged

The quotes that began this chapter were from students who took part in teams whose culture did not promote critique of others’ work — and in all three cases, their projects suffered from the lack of feedback and input. These students did not have a team environment that encouraged constructive conflict (see Chapter 5, “Constructive Conflict”).

Here are four steps your team can follow to develop a culture in which constructive feedback is encouraged:

Two Types of Revision: Feedback and Direct Revision

Teams can handle revisions in two different ways. In the feedback method, one team member drafts some text, submits it to others for feedback, and then implements revisions based on this feedback. This method is sometimes referred to as single-author revision because one person maintains primary responsibility for a section of text. In the direct-revision method, one team member drafts some text, and another member implements the revisions, directly changing and revising the text of the previous author. This method is sometimes referred to as multiple-author revision because several people share responsibility for shaping the text.

The Feedback Method

The main benefit of the feedback method is that it is easy to implement. Since one person maintains responsibility for a section of text, there are no opportunities for version-control problems, in which two people are simultaneously working from different copies of the text and end up writing over each other’s changes. Moreover, the feedback method allows the author to compile comments from several people with different perspectives and can also free up other team members to work on other parts of the project because it usually takes them less time to make comments than to implement direct revisions.

The main drawback of the feedback method is that the quality of the text rests disproportionately on the skills, ability, and efforts of one person. If that person is not a good writer, is defensive about receiving feedback, or does not put sufficient effort or time into drafting and revising, the entire product suffers. For this reason, it is very important to select an author who is highly motivated to improve his or her writing and is therefore eager and willing to listen to others’ constructive comments. (Remember: motivation is often more important than experience when selecting people for tasks. See Chapter 4, “Getting Started with the Task Schedule,” for more advice on assigning team members to tasks.)

Another drawback of the feedback method is the risk of stylistic inconsistency if the team assigns different sections of text to different authors. Even though these authors may be receiving feedback from one another, the document as a whole can sound disjointed and awkward, especially if the authors have different writing styles or “voices.” The following instructor comment on one team’s draft illustrates the potential drawbacks of the feedback method:

Much of the background section is written in the first person plural (“we”) while everything else is written in the third person. The “solutions” and “recommendations” sections sound as if they were written for a much more technical audience than the rest of the proposal. Overall, the document sounds like you divided each section up without consulting each other much.

Each section of this document relied on the writing skills of a different team member, and the document lacked a unified “voice” and structure. To avoid this problem, many teams that rely on feedback for revising individual sections of text in the early stages of the project may switch to direct revision toward the end of the project, with one person editing the entire document to make it sound unified and coherent.

The Direct-Revision Method

The main benefit of direct revision is that responsibility for the text is shared by several people who can draw on one another’s strengths as they directly change, reorganize, and add to the text. Thus, if one person has strong content knowledge about the topic and another has strong writing and editing skills, the team benefits from combining both of these strengths.

The major drawback of direct revision is that the team can end up with two or more different versions of the same document (known as a version-control problem), a situation that can be frustrating and time-consuming to resolve. Version-control problems can crop up when one team member begins revising a document without knowing that another author is also making revisions to the same text. Moreover, in the direct-revision method, meeting deadlines takes on added importance because the original writer cannot make further changes to the text after handing it off without introducing version-control issues. Some of these problems can be alleviated with a Web-based editor such as Google Drive or a wiki. Nonetheless, “handing off” the text from one writer to the next remains a tricky issue in direct revision.

Choosing a Method

Fortunately, you do not have to choose just one of these methods; teams can and frequently do combine them at different stages of the project. For example, a team may rely on the feedback method for global comments on initial drafts and then switch to direct revision to implement minor changes to the wording and formatting as the document nears completion. Or the team can use the two methods simultaneously: a teammate can hand off a document to another writer for direct revision and at the same time ask the other teammates to provide global feedback. Thus, the person implementing the feedback will be different from the person who wrote the initial draft.

Table 6.1 provides a summary of the benefits and drawbacks of feedback and direct revision.

Table 6.1. Feedback versus direct revision

The following questions — while certainly not a complete list of the issues your team should consider — can help you select the method or combination of methods that might be best for your team.

Whether you use feedback or direct revision, you and your teammates should be willing to suggest (or directly implement) both major and minor changes to one another’s writing. Moreover, both methods require team members to be open to receiving feedback and seeing changes made to their writing. With the feedback method, writers must be willing to implement as many of their teammates’ suggestions as possible. With direct revision, writers must be open-minded when someone else changes their text and avoid becoming committed to a particular way of phrasing or organizing the text. To help you handle feedback productively while using either method, the sections that follow offer tips for making and listening to feedback on writing. (See also Chapter 8, “Troubleshooting Team Problems,” for additional advice on how to handle problems with giving or receiving feedback.)

Before You Start: Ground Rules for Revision

When writers submit work to teammates for direct revision or comments, they should take a moment to clarify the state of the draft and what they see as the goals for revision.

Figure 6.1 illustrates how a writer might ask for feedback from teammates, while clarifying what level of feedback she is looking for. In Figure 6.2, one of the writer’s teammates requests direct revision on a draft that is nearly at its final stage.

For their part, reviewers and coauthors need to make sure that they understand the goals of the project as a whole before they respond to the writer. Thus, before responding to or revising a draft, teammates should take time to review the assignment instructions to ascertain what the final product should look like.

Providing Effective Feedback and Making Good Revisions

If you have been assigned to provide written feedback to a teammate or directly revise a draft a teammate has prepared, you should take time to provide thoughtful suggestions. You don’t have to be certain about every suggestion you propose. After all, other people will be commenting as well, and the team can decide which suggestions are good ones. However, you should be constructively critical of the draft. This constructive criticism is key to creating a strong final project and is a major part of teamwork (see Chapter 5, “Constructive Conflict”).

Before you provide feedback or make revisions on a draft, make sure you completely understand the project’s requirements:

Because writers often find it difficult to see shortcomings in their own writing, it is important that someone other than the original writer(s) check the assignment for completeness and accuracy. The document will always benefit from having a “fresh set of eyes” take a look at it.

Once you understand the project requirements and have reviewed the draft, you are ready to give feedback or implement revisions. Depending on how far along the project is, you can use one of the following checklists to guide your feedback or direct revisions.

Listening to Feedback and Negotiating Revision

Responding to feedback may be one of the most difficult parts of working on a team. When your teammates offer feedback or revisions, do not respond defensively. If someone notes a problem, assume that there is some sort of problem — even if that person has mislabeled the problem or presented an incorrect solution. Do not reject any feedback until you have considered it from all angles.

The ability to receive and accept feedback represents a high level of professionalism that, as a student, you may not have had the opportunity to develop yet. If you have difficulty accepting feedback or criticism from others, the strategies in the checklist on page 69 may be helpful.

Sometimes, you will receive feedback that you agree with but don’t know how to implement. At other times, you will receive feedback that is confusing or that you don’t understand. In these cases, don’t simply ignore the feedback. Ignoring your teammates’ feedback can make them feel that you don’t value their work and input — or it can make them wonder whether you are lazy or closed-minded.

Instead of ignoring feedback that confuses you, ask for clarification — or for suggestions about how to implement it. Figure 6.3 illustrates an e-mail from a teammate asking for clarification.

You might also talk to your instructor or a tutor at your university’s writing center about how to incorporate confusing feedback. In many cases, your teammates may have correctly identified a problem in your writing but incorrectly identified the solution. A more experienced writer might be able to help you step back and troubleshoot the document from a different perspective.

Sometimes, you will receive feedback that you simply disagree with. If this occurs, try to give yourself 24 hours to cool off and then reconsider the feedback with an open mind. Suggestions that seem impossible at first glance often look much more manageable when you return to them later. Also, if you reread the feedback, you may find that you had initially misunderstood or overreacted to what your teammate was suggesting. A 24-hour cooling-off period allows you to respond to feedback more generously.

If, after cooling off, you still disagree with the feedback or revisions, ask other team members to comment on the issue. You could ask the project manager to put the issue on the agenda for the next team meeting — or the project manager could e-mail the team and ask everyone to comment on the section of text under debate. Sometimes, another team member can provide a suggestion or insight that helps you find a new way to revise that incorporates the best of both your and your teammates’ viewpoints. If the disagreement continues, make sure that you abide by the conflict-resolution method you decided on in the team charter — and feel good that your team actually had a substantive discussion about an issue. Most student teams suffer from an avoidance of any kind of substantive disagreement (see Chapter 5, “Constructive Conflict”).

If you end up rejecting or disagreeing with the feedback or revisions others have offered, you should provide specific reasons that support your point of view. The best reasons are those that are firmly rooted in the instructor’s guidelines, the goals agreed on in the team charter, or the reader’s needs. Thus, if you are arguing for or against including particular information or adopting a particular organization — and your instructor has not provided you with clear guidelines on the issue — you will have more success supporting your position if you can make the case that this will meet your audience’s needs.

In general, you should try to implement every suggestion your peers provide unless you can clearly articulate a good reason not to. See Chapter 8, “Troubleshooting Team Problems,” for more advice on how to handle specific problems that can occur when you are revising with others.

Technology for Collaborative Revising

There are many revision tools available that can help simplify collaborative revising. Some tools are particularly useful for keeping track of direct revisions and reversing controversial changes. Others are particularly useful for providing feedback on text. Some tools help reduce version-control problems by keeping a single, centralized copy of the text on a Web server where it can be edited by everyone. This section discusses some of these tools, starting with the simplest.

E-mail Message

The simplest technology for providing written feedback is to type your constructive criticisms and suggestions for change in an e-mail message. This method is best for providing large, global suggestions for revision. It is not as effective for making minor suggestions to specific sections of text since you cannot easily anchor your comments to a particular paragraph, sentence, or word.

Commenting Features

Many word-processing programs have a commenting feature that allows you to make comments in the “margin” of a document. Figure 6.4 shows Microsoft Word’s commenting feature. To make a comment, highlight the section of text you wish to comment on, go up to the Insert toolbar, and select Comment. A box in which you can type your comments will appear in the margin of the text. Once you have commented on the document, you can e-mail it to your teammates. (Hint: If your teammates use a different word-processing program, you can convert the document to Rich Text Format [.rtf] before sending it. RTF is a universal word-processing format.)

Commenting tools are sometimes combined with Track Changes (see the next section). In this situation, reviewers make large suggestions in the comments and use Track Changes to suggest minor edits and rewordings.

Sometimes, though, when teams use commenting tools, they can end up duplicating their efforts: if several team members are commenting simultaneously, they might spend time pointing out the exact same problems. Moreover, it may be challenging for the writer to collect separate feedback from several people, thereby increasing the chances that some comments get overlooked. To avoid this problem, the team can adopt a “serial commenting” method, in which the document is passed around to teammates one at a time. Each teammate can then respond to the feedback of previous reviewers as well as make additional comments; however, the serial method will lengthen the time it takes to obtain feedback from everyone on the team.

Track Changes

Track Changes is a revision-control feature in Microsoft Word (other word-processing programs have similar tools) that tracks all additions, deletions, and formatting changes to a document. To turn Track Changes on, go to the Review tab and select Track Changes (see Figure 6.5). Using Track Changes, you can make revisions to a document and then give it to other team members, who can then “accept” or “reject” the changes. Figure 6.6 shows a document that has been edited using Track Changes. Figure 6.7 illustrates how other authors can use the reviewing toolbar to implement changes and to switch among different views of the document.

Track Changes is most commonly used for direct revision (although sometimes reviewers also use it to make minor editing suggestions when providing feedback). This feature allows one author to completely revise another author’s text without anxiety because coauthors can see exactly what was modified and can easily reverse controversial changes. The main drawback of Track Changes is that coauthors have to carefully coordinate with one another to avoid version-control problems, which can occur when several people are working from different versions of the same text.

Google Drive

If several team members are going to be revising a document extensively, the team may want to consider using a Web-based editing environment such as Google Drive (see Figure 6.8) or a wiki-based editor. The main advantage of a Web-based editing environment is that there is only one copy of the document, which stays on the Web site. Multiple authors can edit and revise it without worrying that someone else has a more recently revised version. However, it is usually best to avoid truly simultaneous editing (when two authors are revising at the exact same time) because there are time lags during which one author might move or delete a section of text that another is working on. Thus, truly simultaneous editing can introduce version-control problems into the process — exactly the problem that a Web-based editing environment is intended to prevent.

Most Web-based editing environments keep a revision history that logs who made what changes when. This revision history can help a teammate identify what was changed recently. Revision histories are also good for undoing revisions by reverting back to an earlier version of the document.

The main drawback of Web-based editors is that they offer far fewer editing features than desktop-based word-processing programs. If your document requires extensive formatting or has lots of tables or figures, you may want to avoid Web-based editors.

Google Drive also allows teams to share and collaboratively edit spreadsheets and presentations. Again, these Web-based tools have far fewer formatting options than the word-processing programs you may be accustomed to.

You can find out more about Google Drive and sign up for a free account for your team at https://www.google.com/drive/.

Wikis

Teams can also use another Web-based editing tool for collaborative revision: a wiki, which is a collection of Web pages that allow users to make changes and add new pages. Wikis are particularly useful for putting together complex sets of information. Whereas a Web-based editor such may want to consider using a wiki — especially if your team intends these documents to be open to the public to read, comment on, and possibly even revise.

The main advantage of wikis is that they allow the team to store all the documents associated with a project — including task schedules, external reference documents, discussion boards, instructions, and other materials — in one central place. The main disadvantage of wikis is that they have a much higher learning curve than a tool such as Google Drive, which is specifically designed for drafting written documents. When working with a wiki, team members can easily forget where various documents are placed and can miss important information. For this reason, if you use a wiki for your team project, make sure the team discusses up front a standardized method for notifying everyone of exactly what has been changed or added and where those changes or additions can be found.

It is impossible to discuss all of the wiki options available, but Table 6.2 lists some common wiki features that are particularly useful for collaborative writing.

The following wikis have many of the features listed in Table 6.2:

In addition, you might want to consult Wikimatrix (www.wikimatrix.org), which lists hundreds of current wikis. This site also contains a wizard that helps you select a wiki based on your team’s needs.

More Technology for Revision

Depending on the needs of your specific project, you may want to consider some other, less well-known tools for managing collaborative revision, such as Zoho and Gliffy. Zoho, like Google Drive, is a free Web-based editor. At the time of this writing, it provides a wider range of tools than Google Drive, including an online presentation editor, text chat tools, and project planning tools. It also allows users to import documents directly from Google Drive. However, the sheer number of applications that Zoho supports makes its interface somewhat difficult to navigate. To find out more about Zoho, go to http://zoho.com.

Gliffy is online diagramming software that allows you to create flowcharts, diagrams, floor plans, and technical drawings. You can find out more about this tool at www.gliffy.com.

Table 6.2. Wiki features particularly useful for team writing projects

Selecting a Tool

Table 6.3 summarizes the advantages and drawbacks of the various revision and feedback tools discussed in this chapter. Sometimes, your in­­structor (or supervisor in the workplace) will require you to use certain tools; however, on most projects you will have some choice, so thinking through the pros and cons of various options up front will save you headaches later.

Table 6.3. Advantages and disadvantages of revision tools