Make the shared starting point visible
Identify the file or location where ongoing editing takes place. Give every participant that reference and mark older copies accordingly. A filename containing final is not a sufficient rule if final_new and final_really then appear. What matters is a shared understanding of responsibility for the current state.
Check that everyone has the intended permissions. Someone with read-only access cannot contribute through the same process as an editor. Resolve those differences before the editing period begins. If external people participate, include their approved access route too. An improvised personal copy does not reliably solve the coordination problem and may create another uncontrolled version.
Agree simultaneous editing deliberately
Where the chosen tool supports collaborative editing, test it with the actual file and participating accounts. Formats and environments do not all behave identically. Decide whether people own different sections or submit suggestions first. The arrangement should suit the work rather than being determined only by an available button.
If simultaneous editing is not intended, appoint someone to combine changes. Tie feedback to the starting version and give it an understandable return date. Avoid several independently edited copies without a method for comparing them. Brief coordination before distribution saves later guessing about which sentence from which file was meant to be adopted.
Keep the purpose of changes traceable
For substantial revisions, briefly record what changed and why. This is particularly useful when replacing wording previously agreed by the group. Distinguish editorial corrections from content decisions where that matters to participants. A cleaned-up document may appear finished even though a central claim still awaits approval.
Check the tool's current documentation for ways to inspect or recover earlier states. Do not assume every downloaded copy carries the same history. If an older version is required, make it available separately first and compare its contents before replacing the working file. This prevents a rollback from unintentionally overwriting newer work that should have remained.
Resolve a concrete version conflict
Suppose one person has revised the second section of the shared document while another has corrected an older downloaded copy. Do not simply replace the shared state with the returned file. First compare the changes contained in both. Have the responsible person combine them traceably, then inspect the places where revisions overlap particularly carefully.
Keep the two starting states separately during the comparison so that premature overwriting does not lose information. Label them as comparison copies rather than calling both current again. After combining the changes, tell participants where work will continue and which feedback has been included. Silently replacing a file may leave someone else still editing an obsolete starting point.
Use the conflict to address its cause. The shared link may have been difficult to find, someone may have been unable to edit while travelling, or the feedback process may have been unclear. Another version number does not fix those causes. Agree the missing transition for the next round: perhaps a labelled feedback copy containing comments only, or a defined consolidation period owned by one person.
Separate approval from distribution
Identify the version submitted for review and where its approval is recorded. Later changes should remain identifiable if they affect an approved statement. An export prepared for distribution needs a clear relationship to the reviewed version. Keep the editable source where the next revision is expected to begin.
Finish with a small check: can two participants independently locate the same current file? Is it clear which copy is only for viewing? Are unresolved comments visible? If so, the collection supports collaboration. If not, adding more numbers to filenames alone is unlikely to resolve the underlying uncertainty.
