Following on my recent post on document-comparison etiquette, longtime reader Jim Brashear sent me the following:
I’d be interested in reading others’ thoughts and comments on document filename conventions and etiquette. For example, one distributes a set of draft documents with filenames (descriptive or otherwise), and one receives back from various counterparties their edits in documents with completely different filenames (sometimes merely a number randomly generated by their document management system).
When I am not controlling the drafting process, I generally return comments in a file using the original filename with my initials and edit date appended in parentheses, e.g., “originalfilename (JFB edits 15Jul2010).doc.”
When entering into my document management system a file that someone else is controlling, I input the document name followed by their filename in parenthesis. I also set my system so that exported files sent to the counterparties are named using the full document name (with the original filename in parenthesis) rather than merely a document number generated by my document management system.
As with document comparison, this issue doesn’t come up in what I do. I leave it to you, readers, to offer your thoughts.
9 thoughts on “File-Naming Etiquette”
I too have followed a similar naming format.
E.g. Master Services Agreement_ECM_Edits_Jul_12_2010, or Master Services Agreement_ECM_Clean_Jul_12_2010 (since I usually include a 'clean' version as a courtesy).
If there are two reviewing lawyers (maybe even three), then you could still use everyone's initials… e.g., Master Services Agreement_EM_KA_QZ_Edits_July_12_2010.
But if there are more than three lawyers (quite common in large deals), then the name of the client or corporation should be used. E.g., Master Services Agreement_IBM_Edits_July_12_2010.
I don't think that people should be relying on too much of anything in the filename. That's a pretty silly expectation. In addition, I think that filenames usually come back in a way that is only meaningful to one side. So unless you follow some generally acceptable naming convention, I'd wager you're not likely to see the same file name come back.
Furthermore, as some of the above examples illustrate: the file name is too crowded to convey any meaningful information. In short, how you track a file internally is totally up to you.
But, as long as we're at it, I think that as a general rule, I follow the etiquette of KISS. Here's a few of thoughts:
0. Clear, meaningful titles are best. I typically follow the convention [Party A] – [Party B] – Title of the Agreement (see #2). Anything that conveys similar meaning is probably fine. If it's an exhibit or some sub-document, I usually note that too. In general, I find that few people mess with the filename if it makes sense.
1. if your document management system attaches a file identifier, don't expect that it'll be retained. The other side is likely not to dwell too much on it. And, if the other side's system appends an identifier, it's only going to make the filename worse. If you need to, keep your ID in the footer of the document. You can always "file->save as" to change the name of the attachment, if you have to.
2. Generally speaking, I only care about the party generating a particular draft. Even if a draft does so indicate, I will usually update/add a parenthetical [filename] (Party X). The draft date is usually unnecessary because its usually implicit in the other metadata.
3. If you're producing two versions of the same draft (e.g., clean/redline) identify those towards the beginning of the filename since Outlook and other e-mail programs (blackberries, etc.) tend to truncate long file names. If you're not sending two drafts, no need for the clarification in the filename. You can make the relevant disclosure in the cover e-mail: e.g., I have attached a redline showing my changes from the last draft.
Wow. WAAYYYYY more complicated than it needs to be. But for etiquette, I follow a few simple rules:
1. NEVER change the base name of the document. If you do, it doesn't sort well with the others and managing multiple versions becomes problematic.
2. In both Windows and MacOS, I always want to formulate a document suffix so that changes will keep the documents in revision order. This usually means adding "v# mmddyyinit" to the end of the file, where # is the sequential version number, mmddyy is the month/day/year of the edit and init are the initials of the revision's author.
Document management systems obviously introduce another layer of complexity… but for the most part, you can override their autonumbering process.
The result of this simple system is that I can tell who edited the document, when it was done and where it falls in sequence. If the other side doesn't play along, I simply add the suffix to their documents as I'm saving them into my folder structure. As stated before, it allows for proper sorting in all OS's (since it sees the v# part first and sorts based on that), which is important … especially when you have 3+ documents within a particular contract portfolio (such as a NDA, a Master and a SOW).
Pet hate: suppose you are or represent XYZCorp. The other side calling the document "XYZCorp contract.doc" is deeply unhelpful. Include both parties in the document name.
Favorite suggestion: Keep the document name the same, but append a date in the format YYYYMMDD, then whoever has edited it etc. Why YYYYMMDD not the more usual formats, i.e. DDMMYYYY or MMDDYYYY? This ensures that an alphabetical sort of files in that directory retains them in date order of edit (as opposed to sorting them by date they happened to be saved to the disk, which may differ if you extract versions from old emails etc.)
Note that inaction by leaving the filename the *same* can also raise a host of issues (e.g., resending the document, saving it, and causing someone to unintentionally confuse the two documents of the same name, or — heaven forbid — save over the original document).
When I receive a document and save it into my system, I usually change the name to fit my profiles, especially if I am saving it as a new version of an existing document. I expect the other side to do the same. I append the date of the draft at the end, in international format yyyymmdd.
I have only one pet peeve in fle naming — any file that suggests the other side's comments are actually mine.Similarly, I usually put "[Name of my firm] Comments HHMnMnYYYMMDD" at the top of page one; if I get comments back from the other side that do not include a change to that banner, I will usually send an email to everyone who received it, with a cc to whoever sent it, pointing out that the document claims to be my comments but actually reflects the other side's comments, and to please mark their copy accordingly.
In pursuit of the elusive perfect file naming convention, I would suggest Jeff G’s method modified by Alex Bligh’s suggestion (which is what I use) but with the following further tweak.
My file names, for version purposes, are in the format “v# YYYYMMDD”. However, I only change the version number (i.e. the “#”) once the document is ready to send to the other party. While fine-tuning it with my client, I will only change the date. For (a rather long) example: I receive “v2 20100615” from the other party and forward it to client; I edit it over two days, change the file name to “v3 20100617”, and send it to client; client reverts with comments on my edits; I edit it further over two days, change the file name to “v3 20100619” and send it back to client; client reverts again with more comments; I edit it further over one day, change the name to “v3 20100620”, and send it to client; client approves it and I send that version (i.e. “v3 20100620”) to the other party.
This achieves two things:
1. It helps me keep tack of which iterations have been sent to client only (i.e. are works in progress between client and me) and which have been sent to client and to the other party (i.e. are firm proposals to the other party).
2. Tactically, it does not indicate to the other party how much to-ing and fro-ing there was between client and me. In my example, if I changed the version number with every set of edits, I would send “v5 20100620” to the other party, which would indicate to the other party that there may have disagreement between client and me.
In the rare event that there are two or more iterations on the same day, I merely add “A”, “B” etc to the end of the second, third etc iterations.
I am lucky enough to work with investment fund documents, most of which are not negotiated, and so I always create new documents using the following format:
[Type of document] – [Name of Fund] – [Month and year]
e.g. "Distribution Agreement – Mega Return Fund Limited – July 2010".
I work with document management systems which automatically generate document numbers and new version numbers in the file name as well, and I note in the metadata when new versions have been saved. I don't add a precise date until the document is finalised, if ever, as the exact date I created the document isn't important and I'm not going to keep changing the file name. But I think the most important thing is to have a system and stick to it, whatever the system is.
For documents sent by the other side, I generally keep their name to avoid confusion, unless it is something completely unhelpful (like a number).
Does anyone else include version numbering in the document, so that this info is evident on the printed document? I have been including a coded footer that indicates (to me) the file path to the document on our server, date the drafting of that document started, and a version number.