Tags

,

Claire Aitchison

In my experience academic writers often create fairly idiosyncratic systems for naming and sharing word documents. However, when authors need to collaborate, share, and review documents together, these individual systems can collide causing mix-ups and frustrations.

For example, one area for confusion can arise when a file is marked FINAL – with all the certainty and boldness the capitalisation deserves! Sparked by this quandary, here I reflect on practices for the naming and exchange of writing between supervisor and candidate.  This post gets its energy from the promising idea of a FINAL draft, and suggests some practical ways to avoid confusion when drafts pass between supervisors and candidates.

There is a seduction, a promise, a hope in the term ‘Final’. There is also a closing, a release, a sense of completion and satisfaction from employing the term. It is a shared longing, but not necessarily a shared perception of the state of affairs.

What does ‘Final’ mean?

Does Final mean one or both supervisors have finished their reviews and do not wish to see the chapter again? Does it mean the work is ready to go to the printer, to be submitted, or ready to go to a paid editor (if that is allowed at the conferring institution)?

When a doctoral student sends their supervisors a chapter marked ‘FINAL’, are they taking agency and showing their own critical evaluation? Or are they calling out that they have had enough? This is it. No more. Or, does it simply mean, for now, this is my final version?

Whether as author, co-author, student, or doctoral supervisor, I expect there would be few of us who have not had the unsettling experience of finding more than one version of a document labelled ‘Final’. Indeed, recently I joked with a colleague: How many Finals does it take to finish a PhD? (Let us know if you have the answer!)

Clarity around naming of documents

We have written before about the importance of good file management. Researchers, collaborators, and the members of supervisory teams share a common need to exchange files regularly and to do so with clarity about versions and editing/feedback cycles.  The naming of files can play an important role in this, and yet, there doesn’t seem to be agreed or widely practiced method. 

Even when documents are open for access between numerous people (such as shared in Google Doc), naming and turn-taking conventions can be confused.

In my opinion good file naming conventions mean I can easily identify the author, the contents, the version, and, when necessary, the identity and sequence of reviewers. My preference is to know this information, in that order. I’ve worked out one way of doing this which I’ll explain – but we’re keen to hear about other practices too. Minimising confusion and errors that can maximise efficiencies is in everyone’s interests.

Here are my basics:

  1. Agree on the conventions: Have a discussion to establish your shared practice early on. Be aware that institutions and relevant research/ethics bodies may have advice/ practices you should be cognisant of. 
  • Be consistent. Stick to your agreed conventions and apply them consistently over time and across different kinds of documents (unless it really does need revising). 
  • Whose is this?  Because supervisors are likely to have more than one student, make authorship clear. I favour initials at the beginning of the file name.
  • What is this?  File names need to indicate what is contained therein. Be informative, even if this means names need to be longer than you would like. Avoid cryptic, and obscure abbreviations. For example, doctoral work can sometimes be simply described as MJ-Chapt 1 (that is, author: Mahira Jaraha, content: Chapter 1). At other times we need to indicate this is significantly different from previous versions, as this modification shows: MJ-Chapt 1_NewIntro.
  • Haven’t I already seen this?  Having established authorship and content, provide information that indicates which version this is. In my view, this cannot be adequately indicated by writing Version 2 (or v2). As a doctoral student, you are probably keenly aware of how many versions you have exchanged with your supervisor – but they, on the other hand, are unlikely to know if this is the 4th or the 14th version … they will have lost track. Date is a far more reliable indicator. And here’s another tip – please include the year (yes, you will be returning to manuscripts that are years old…).  I do it this way: MJ-Chapt 1_150221 (that is, Mahira Jaraha, Chapter 1, circulated on 15th February 2021).
  • Who is to read and review this? So far, it is relatively easy – the bigger challenge is naming documents that are shared with different people individually or sequentially, as occurs commonly within supervisor teams. This is about keeping track of the reviewing process. It can be a nightmare trying to record who has seen and worked on the document last. One of my students introduced me to this convention when she sends work only, or first, to me: MJ-Chapt 1_150221_for CA (that is, Mahira Jaraha, Chapter 1, circulated on 15th February 2021 to Claire Aitchison for review). 
  • Who is next? Using the same example, when I return it to MJ and/or pass it on to the next supervisor, I adjust the end of the file thus: MJ-Chapt 1_150221_afterCA_280221 (that is, Mahira Jaraha, Chapter 1, originally circulated on 15thFebruary 2021, and returned after it has been read by Claire Aitchison on the 28th February 2021). 
  • And what about other readers? This system allows for additional reviewers to be added, for example, a second supervisor reviewer receives this document into which I have already provided feedback. Then, with his feedback added, he returns the document to us naming it thus: MJ-Chapt 1_150221_CA_280221_SL_140321. 

Clearly, the file name is getting long and cumbersome, so, it may be appropriate to drop off unimportant details. For example, if this is a closed circle of exchange and no one is likely to need reminding of the author, or if the date of the first draft is no longer relevant, such components could be left off – but beware, changes can alter the automated sequencing order.

As I write this, my system seems more complicated than I realised! If nothing else, I hope this post will encourage you to create something better. However, whether you use my ideas or other conventions, what’s important is that your practices for exchanging documents are sustainable and clearly understood by all the users.