Keep manuscript versions clear when drafts move between co-authors
Keep co-author manuscript handoffs clear with an agreed working copy, meaningful filenames and an original fictional version-and-reconciliation ledger.
About 5 min read · Allow extra time for the practical checks
Agree which file is the working manuscript, how returned comments will be identified and who will reconcile them before you send the next draft. A filename helps, but it cannot decide which of two conflicting revisions your team intends to use.
This is a small document-handoff workflow for manuscript prose. It does not prescribe a data-cleaning audit trail, a particular collaboration platform or a replacement for your institution’s storage and retention requirements. If your team already uses a workable system, document that system rather than adding a competing naming convention.
Write the rule before renaming the files
The University of Cambridge’s file organisation and version-control guidance recommends an agreed, consistent naming approach, meaningful folder organisation, version numbers and a record of changes. Princeton’s records-management guidance also describes identifying returned revisions and agreeing who marks the final draft.
For a manuscript, turn those general principles into a short team note. State where the working copy lives, who reconciles returned edits, what a version change means and how a co-author should label a returned file. Include what should happen if two people need to edit the same section at once.
“Use the latest file” is not enough. Latest by email arrival, local modification time and team approval may refer to three different things.
Walk through a fictional handoff
The project, initials, dates and files below are invented teaching examples. They are not actual author records or a required filename standard.
Imagine a two-author teaching paper called the Orchard project. The team agrees that Nila reconciles edits, that v01, v02 and so on identify consolidated team drafts, and that returned comments keep the version they were based on. A date means the date that particular file was prepared. The team uses an approved shared location for the working copy.
| File or record | Meaning in this fictional workflow | Next action |
|---|---|---|
| orchard-v03-20261020.docx | Consolidated draft sent for comments | Keep this as the reference for that review round |
| orchard-v03-20261022-OP-comments.docx | Omar’s returned comments on v03 | Nila reviews these against v03 and the current working draft |
| orchard-v04-20261024.docx | Reconciled team draft | Record the accepted changes and remaining questions |
| Version note for v04 | Introduction shortened; definition corrected; interpretation question still open | Ask the team to resolve that question before submission |
Suppose another attachment named orchard-final.docx arrives after v04. Its later arrival does not make it the new master. First establish which version it was based on and what it contains. Compare its changes, reconcile any conflicts and record the agreed outcome. Do not overwrite v04 merely because the attachment says “final”.
Keep the version note useful
A compact log can record the version identifier, date, person preparing it, important changes and unresolved questions. Describe changes at a level that lets a co-author find them: “clarified the definition in the second introduction paragraph” is more useful than “improved writing”.
The log is not evidence that every change was correct or every author approved it. If approval matters, record it through the team’s agreed process. Distinguish a reconciled draft from a draft that has received all required approvals.
For substantive comments, link the note to a section, paragraph opening or other stable locator. Page numbers alone may shift as the text changes. The guide to giving useful draft feedback explains how to make the comment itself actionable; this workflow makes clear which draft received it.
Avoid two silent working copies
Before editing, open the agreed working location and confirm the current identifier. When you hand work over, say what you changed and what needs a decision. If you will edit offline, agree how that copy will return and how overlapping edits will be reconciled.
Built-in version history or tracked changes can help inspect edits when your chosen software supports them. Do not assume that sending a copied attachment preserves the original history, or that a tool’s newest revision represents team agreement. Keep the handoff rule understandable even to someone joining the project later.
When editing a shared report, resolve both wording consistency and version identity. A clean-looking document can still omit a co-author’s unresolved correction if nobody reconciled the returned copies.
Close a submission round deliberately
Once the team has completed its checks and approvals, label the agreed submission set and retain the exact files actually submitted through your approved storage process. Record which manuscript version they came from, including separate figure or supplementary files when relevant.
Do not interpret archiving as permission to delete earlier files. Follow the retention and recovery requirements that apply to the project. A second copy in another folder is also not a substitute for the backup arrangements your team requires.
The practical test is simple: can a co-author identify the agreed draft, see what changed since their last review and find the questions still awaiting a decision? If so, the filenames and notes are doing useful work.
