How to Use Change Tracking Effectively When Collaborating on Documents

/in , , , , , /by

Long gone are the days of printing a document, marking it up with a red pencil, and sending it back to the author to input the changes. In the modern world, we use comments and change tracking to collaborate in word processors like Microsoft Word, Google Docs, Apple’s Pages, and Nisus Writer Pro. The specifics vary a little by app, but in essence, once you turn on change tracking, every change you make becomes visible to others working on the document, and they can accept or reject the change. Changes and comments can also host brief discussion threads.

In this article, we’re going to recommend general ways of working with change tracking and comments, rather than exploring the particular interfaces in different apps. This advice should work well for all apps that support change tracking and comments.

Establish a Working Approach

There are two typical scenarios when working with others on a document. Either you’re collaborating with colleagues to create the best possible final document, or you’re negotiating over every change, as might be the case when constructing a legal agreement where people have conflicting goals and agendas. We’ll focus on the former since everything gets tense when multiple people have to sign off on every change. If you end up in an editing scenario that’s essentially an arms-length negotiation, you’ll probably make fewer changes and examine each one closely.

Assign Roles

Talk with your fellow collaborators to clarify who will be doing what. Depending on your workflow, a document will have people in two or three roles:

  • Author: The author drafts the document without change tracking enabled. Subsequently, the author accepts changes made by the editor and contributors.
  • Editor: The editor enhances the author’s text with change tracking enabled and accepts the author’s subsequent changes. (An editor isn’t necessary as long as everyone else doesn’t mind the author accepting their own changes later.)
  • Contributor: Everyone else is a contributor, and they only make changes in change tracking mode. They neither accept nor reject changes.

These roles make it clear who can and should do what. Otherwise, you end up in a situation where people are hesitant to accept changes or where someone accepts changes before the author has seen them.

Even with these roles, the order in which the document gets reviewed can matter if you want certain contributors to see what’s changed, even if they don’t accept the changes. Generally speaking, people take turns with documents, with communication via email or some other channel to let others know when they can dive in.

Some documents may need only one editing pass, whereas others will require several. You’ll know you’re done when all changes have been accepted and comments have been resolved.

Decide Which Changes to Show

When you enable change tracking, every change will be tracked. That can be counterproductive if the number of changes becomes overwhelming—to either people or the software. You may wish to make certain changes without change tracking enabled or accept them before the next person’s turn. For instance:

  • Formatting changes: If you’re changing styles or putting text into lists to make a draft more presentable or professional, those changes can quickly clutter the document and are usually not controversial.
  • Consistency changes: For ensuring consistent usage, such as one space after a period, a search-and-replace with change tracking disabled lets the next person avoid dealing with hundreds of small changes. You can leave a comment at the top of the document noting what you did.
  • Minor proofreading changes: Everyone makes typos. You may wish to keep typo fixes visible to show how much your editing has improved the document, or you can accept them right away to save the next person time.
  • Too many changes to parse: At times, you may edit a paragraph so heavily that it has been almost entirely rewritten. As with proofreading changes, you might want to keep those changes visible to indicate how much you’ve done, or you might want to accept them all and leave a comment saying, “Read this paragraph carefully—too many changes to show with change tracking.”

Accept (Don’t Reject) Changes

When it comes time to review changes, apps let you either accept or reject changes. We usually recommend accepting changes even if you disagree with them. That’s not to say you have to stick with a proposed change that you dislike, but the person who made it did so for a reason, and it’s up to you to figure out what that reason is and recast the text to accommodate it, preferably with an explanatory comment. That way, they’ll see your change on their next pass and can decide if you addressed their concern.

Occasionally, someone might negatively change some carefully worded text because they didn’t realize why it was worded that way. Rather than rejecting such a change, leave it and start a discussion. In all likelihood, they’ll withdraw the change on the next pass, or you can reject it once they see where you’re coming from.

When accepting changes, you can employ several techniques:

  • Few changes: If there aren’t that many changes, it’s easy to accept them one at a time. As you do this, watch for mistakes that creep in—missing or double spaces, verb tense and number mismatches, and so on. These can be easy to introduce and difficult to see while editing.
  • Many changes: When the entire document seems to have changed color because there are so many changes, it’s easier in most apps (other than Google Docs) to select a paragraph at a time, accept all changes in the selection, and then read it closely to make sure the changes are both helpful and don’t introduce additional mistakes. A keyboard shortcut to an Accept Selected Changes command can make this process faster.

We don’t recommend using the Accept All feature to accept all the changes in the document unless it’s quite short and you plan to read the entire thing carefully again.

Dealing with Comments

Finally, some comments about comments. In most apps, you can add a comment to a change and start a threaded discussion about the change. That’s extremely helpful if you want to explain why you made the change. However, that approach works poorly if the next person wants to accept your change and continue chatting in the comment, since accepting the change will close the comment thread. As such, we recommend restricting change-specific comments to non-controversial situations where you’re merely informing the next person about why you made ​the change.

When you need to ask a question or raise a topic for discussion, do that in a standalone comment instead, so the discussion doesn’t disappear with the accepted change. Even in this situation, however, you have to be careful. If you select a particular word and start a discussion asking if it’s the right word to use, the next person may not be able to change that word without deleting the comment thread. One solution is to select a few words before the text on which you’re commenting, or just the period ending the sentence, so changes can be made while retaining the comment. Another approach is to select more text—the entire sentence or paragraph that contains the text in question—for the comment. That’s more effective, but too many such comments will overwhelm the document with large colored comment blocks.

Who should resolve comment threads? Although some comments are purely informational and can be resolved by the person to whom they’re addressed, it’s usually best if the person who started the comment thread resolves it. Let’s say the editor leaves a comment that asks a question. The author responds, so the editor needs to see that response. If it doesn’t fully answer the initial question, the editor can ask for more information, and the author can provide it. The editor can then resolve the comment to indicate that the final comment from the author closed the topic.

One last point. Comment threads within a document are useful but limited. If a topic needs significant discussion, break it out to email, Slack, or even a meeting rather than going back and forth within a single comment at length.

We hope this advice makes your collaborative editing faster, easier, and more companionable—remember, the goal should always be to improve the document. However, there’s room for tweaking within these general guidelines to create the ideal workflow for your group.

(Featured image by iStock.com/FrankieMea)