Skip to content

Reviewing Edits

Most word-processing software offer change tracking, the ability to show what changes were made to a text, which provides the most basic feature allowing for authors to review edits. It is typical, though, that the sheer number of edits makes reviewing edits using just this feature tricky, with the more significant changes that need attention being buried under many insignificant edits.

So I pick out areas of text in need of further attention using comment facilities. I use a set of abbreviations to classify these, allowing for shorter, and more quickly acted-upon comments. For an explanation of this scheme, see the list of my Abbreviations for Editing Markup.

There isn't really such a thing as the ratio of comments to all edits: longer texts tend to require fewer explanations, since passages in need of discussion become increasingly likely to have already been explained in an edit, and because I tend to acquire a firmer grasp of what the author is saying, and am more often sure of how to fix an ambiguous or incomplete text. The extreme opposite case is that of the sample edit, needing much explanation; I discuss this in The Sample Edit.

I try to make sure that the end document has the quality that all the English is correct, even though there may be issues I raised in comments where I doubt that the manuscript really says what was intended. This is not always possible for me: for those manuscripts that contain a passage for which I am unable to find a reasonable fix for a passage, I highlight it in blue.

Microsoft Word

Microsoft Word's change-tracking feature, Track Changes, is the most widely used system for reviewing edits, and despite some annoyances, such as the inability to comment within footnotes, it works very well. If you're not familiar with some of Word's options for reviewing tracked changes, however, working through them can be hard work.

It generally makes sense to first deal with the issues that require most judgement to resolve; this means the blue highlight text first, and then the comments. Conveniently, Word has two menu actions allowing you to move from each comment to the comment before or after, and the ability to search for coloured text. Once each comment has been dealt with, it makes sense to delete it — it is possible to review all the comments again from the version I sent: this way the set of comments reprost the "state" of the document, only indicating the outstanding issues, and if new issue come up in review, they can be added.

Then comes the mechanical task of looking over the pieces of text inserted and deleted from the original. If there are dozens of these together, it is much faster to look at all of the edits in a paragraph, reject the changes you disagree with, and then highlight the whole paragraph and accept all of the remaining changes.

It is also possible to view the final version of the document without changes, read through this to see that you find the text acceptable, and then accept all changes in the document together. If you are a careful reader, and have taken into account the issues raised in the comments, then this works perfectly well.


Reviewing changes to LaTeX documents is much more of a free-for-all than Word, because there are so many choices in how to go about it. The two I have found best are:

  1. Load the LaTeX source into a new Word document and edit that the same way as any other Word document. This would work much the same if we were to load the source into OpenOffice Writer.
  2. Put the LaTeX source into shared distributed version control repositories (DVCS). This allows both of us to work on the document concurrently, which may be valuable for longer assignments. Using LaTeX macros to implement comment facilities, and latexdiff to give a snapshot of the changes made between two states of the manuscript, help with reviewing changes.

Other technologies

OpenOffice Writer and Adobe Acrobat's comment facilities don't allow comments to be associated with a highlighted text, but instead point to a particular place in the document. I use the same comment scheme, where "highlighted text" is interpreted to be some region of text following the comment.