How Assistant Editors Track Revision Rounds Across Multiple Editors on a Single Project

On a single-editor project, version tracking is relatively straightforward. One person owns the timeline. They know what round they are on and what changed. On a multi-editor project, that clarity evaporates fast. Editor A is cutting scenes four through eight. Editor B is working on the opening sequence. The assistant editor is managing both. If version tracking is not structured deliberately, you end up with timeline files that cannot be reconciled and notes that reference versions no one can find.

Tracking revision rounds across multiple editors on a single project is genuinely one of the trickier coordination jobs in post, and it is one the assistant editor typically owns. Here is how to do it without losing your mind.

The Core Problem With Multi-Editor Version Tracking

The problem is not that editors are careless. It is that two editors working simultaneously produce parallel version histories that have to be merged. Editor A's version two and Editor B's version two are not the same thing. When those timelines eventually need to be combined into one master cut, someone has to know which notes were applied to which version and whether they are still relevant to the merged timeline.

If you are tracking all of this in your head, or in a text document, or in a spreadsheet that lives on one editor's desktop, that information is fragile. It is one sick day or one bad crash away from being gone.

Establish a Master Version Number at the Project Level

The first step is establishing a single version numbering system that applies to the project as a whole, not to each editor's individual timeline.

Here is a practical structure: the master project has a version number. That version number only increments when a consolidated version has been assembled from all editors' cuts. Within a version cycle, editor-specific timelines have a suffix: V03_EditorA, V03_EditorB. Those are contributions to master version three, not versions three of separate projects.

This sounds like a naming convention conversation, but it is actually a conceptual one. When editors think of their timeline as a contribution to a master version rather than their own autonomous version, the coordination becomes much cleaner. The assistant editor assembles the master, stamps it with the project version number, and that is the version that goes to review.

Centralize the Client Review at the Master Version Level

No editor-specific timeline should go to the client. The client reviews the master version only. This is the assistant editor's job to enforce.

When editors submit their sections for assembly, they go to the assistant. The assistant assembles the master, does a quick QC pass to make sure the assembly is clean, and uploads the master version to the review platform. To understand how version stacking works in practice, see the post on how to set up a version-controlled edit review system. Notes come back against the master version, not against individual editor timelines.

This means the assistant editor needs to know, for every note that comes back from the client or director, which editor's section it falls in. That is the routing function. When review notes come in through PlayPause's video review tool with timecodes attached, the assistant can look at 0:24 and know that is Editor A's sequence, pull the relevant note, and route it to Editor A's session.

Keeping a Change Log Per Version

The change log is the assistant editor's most important tool. For every master version, the change log records:

• Which editor's sections were updated and what changed
• Which notes from the previous review round were addressed
• Which notes were deferred (and why)
• Any technical issues flagged during QC

This does not have to be elaborate. A shared document with version-numbered sections works. What matters is that it exists and is updated every time a new master version is assembled.

The change log serves two purposes. First, it lets you quickly brief the client on what was addressed in each round, which makes review sessions faster. Second, it gives you a record when questions arise later: "Did you address note 12 from round two?" Yes, here it is in the log, addressed in version four.

Managing Note Conflicts Between Editors

On long-form projects with multiple editors, note conflicts arise. Editor A's version of a transition affects Editor B's opening shot. A note on the assembly creates a conflict between two editors' creative choices.

The assistant editor's job when this happens is not to adjudicate creative decisions. It is to flag the conflict to the supervising editor or director and get a clear ruling before routing the note. An unresolved conflict that two editors both address differently creates a double assembly problem that is painful to untangle.

For more on the broader coordination challenge when multiple people are producing notes on the same cut, how editorial teams prevent duplicate notes when two producers review the same cut has the relevant structure.

• Set project-level version numbers before any editor starts
• Never send an editor-specific timeline to the client
• Assemble the master before every review upload
• Route timecoded notes to the responsible editor
• Update the change log for every version assembled

Using the Review Platform to Track Round Progress

A practical benefit of using a dedicated platform like PlayPause for the review loop is that the round structure is visible to everyone. You can see which notes are open, which have been marked resolved, and which are still pending. That visibility lets the assistant editor confirm that all notes have been routed and addressed before uploading the next master version.

Without that visibility, the confirmation is manual. You have to go back through every email thread and check. On a project with four editors and three rounds of client feedback, that is a genuine time sink.

With a platform, it is a two-minute check before you start assembling the next version.

For assistant editors who also manage the handoff to other departments after the edit is locked, the picture lock to sound design handoff checklist is essential reading for making sure nothing falls through between departments.

For a broader look at how to keep approval status visible across multiple deliverables, how post production coordinators keep track of approval status across five deliverables covers the coordination layer above the edit.

The Infrastructure Underneath

All of this assumes you have the right infrastructure. A shared project server or a NAS that all editors can access for media. A clear folder structure for editor-specific timelines and master assemblies. And a review platform that all editors and clients can access without complexity.

For the review side, PlayPause's Agency plan at $19 per month gives you a workspace where every version is stacked, every note is timecoded, and every approval is logged. Free guest access means the director, the client, and additional editors can all be on the same project link without adding to your per-seat count. Set it up at the start of the project and the version tracking problem largely manages itself.