The question of what file is the “actual” file, was it Book_Final or Book_Final2, or was it Book_NewFinal or Book_Final_Corrected? This sort of confusion is almost always born from a benign renaming of a file and only gains speed from the fact that multiple contributors (be they author, editor, or design team) will want to save a copy. Soon, one will be working through corrections in an older draft while the other is adding comments to a new draft. It pays to get version control out of the gate before editorial decisions start bleeding into a few different files.
A file name should include the project, the stage, and the version of the draft. Atlas_Copyedit_v03 provides this level of detail, which the name Atlas_Latest lacks. The stage provides context regarding what sort of work is in the file. The version provides a numerical ordering. Dates can also be helpful in this regard, especially if your files are being sent to more than one person, but be sure to standardize them as they can otherwise prove difficult to sort.
Take five copies of the attached sample manuscript and rename them, in turn, as versions 1-5 of the manuscript. Then rename them, in turn, as manuscript review, copyedit, author review, proof corrections, and approved text. Put the active file in your “active” folder and all the other files in your “archive” folder. That seems too simple, doesn’t it? Yet it’s easy to see how adding visible structure can greatly improve the clarity of the project.
One file should always be considered the master file, though the older draft files should never be deleted. Archive copies can be useful if you need to recover a paragraph or verify a previous decision. The master file just means the current approved text from which the next version should be created. You shouldn’t need to guess that the “final” or the “new” file is the master file, as this should be evident in the production record, the folder system, or the file name.
Tracked changes and comments also need to be handed over in an orderly fashion. Once a draft is passed back to you and you’re making the next version, make sure to review what was done: were the changes accepted, rejected, or is the item left alone? Author questions and comments should never disappear by being incorporated into the clean text and copied into the new file. At the close of every approval stage, save the next numbered file version with a record of what changed: it’s enough, for example, to note that “author’s responses were added; three author questions remain open.”
Confusion often arises when a number of people are editing multiple, localized copies simultaneously. Both files may have useful changes, but merging these into one can create issues like duplicate text, missed comments and annotations, and clashing decisions on things like style. Identify who should control the master file at each phase of the process and the deadline by which contributors are expected to send back their changes. A shared folder can be a great resource for these purposes but only if people follow your agreed-upon file naming and approval systems.
If you don’t know the name or location of a file, you should know three things from the file name and where the file is: which project it’s part of, what phase it’s for, and which version it is. This file should be the active one or an archive. If these three things aren’t obvious, you should rename and relocate it before proceeding to the next draft. Good file versions are visible at a glance.