In a previous Tip of the Week, I discussed the importance of file-naming conventions to maintain document version control, outlining the process we use for the Copyediting newsletter. I was reminded last week that version control goes beyond file names, however.
One of my clients publishes industry papers, and once we get to the layout stage, we use project-collaboration software to track the publishing process among the five team members. Because the software is designed for collaboration rather than publishing, it allows more than one person to own the document at a time. That is, all five of us could download the document and upload new versions. We could all have tasks for one document assigned to us concurrently.
Can you see the potential problem here?
Everything runs smoothly as long as only one person owns the file at a time. Two people can pass a file back and forth with no problem. Add a third person to the mix, however, and you put your version control at risk.
It’s tempting to include a third person to the publishing process when you’re under a tight deadline. I fell to that temptation last week. After I had proofed a file, I had a question for the editorial director. Instead of assigning just the director the task of answering the question, I also assigned the designer the task of making corrections. It would be more efficient and free me up to work on the next document, I thought.
From this point, several scenarios could have happened:
- The director picks up the file first. He answers my question and then uploads the updated file to the system for the designer to work on.
- The designer picks up the file first, and one of three things happens:
- He makes my changes and then waits for the director’s input before finishing the project—an inefficient use of time, at the least.
- He doesn’t see the query. He makes my changes and passes the file back to me. The query means wasting time as I reroute the file to the editorial director for input and then to design for more changes.
- The director and designer pick up the file at the same time and work on it simultaneously. Whichever file is uploaded second is missing something, and the designer is going to have to make another round of corrections. Another waste of time.
In my case, splitting tasks worked, but only because there were no other corrections in the file. Once the director answered my question, then the designer made the change. Yet it made me think: if there had been other corrections, any of the other scenarios above could have happened.
With modern technology and teams working in different locations, we can easily forget the importance of allowing only one person to work on a file at a time.
The notable exception to this is a review or comment stage in which several people comment on the document and hand their comments to one person, whose job it is to merge all the comments and rectify any opposing comments.
Don’t split the publishing process. It may seem more efficient at the time, but in reality it costs time and risks errors making it into the published document.