Help:File naming convention

The naming convention outlined in this document is intended to facilitate the organization and retrieval of documents produced and archived by the Dried Fish Matters project.

All documents stored in the project data management systems should be named according to this guideline. This includes all project-generated files shared through OneDrive, Dataverse, Zotero, and the DFM website.

Although it is preferable that document authors should follow the naming convention at the time of document creation, the project management team may also rename shared documents as necessary to maintain a consistent naming protocol.

Rationale

1. Deep folder hierarchies are opaque and time-consuming to navigate, and potentially challenging to maintain if the document classification system is complex or needs to change.
2. Conversely, information-rich filenames are identifiable in a shallow context (e.g., when shared by email or surfaced in a directory search), as their content can be determined independently of the storage location path.
3. Groups of related files can be listed and sorted meaningfully if the name components follow a general-to-specific data pattern. Filenames that include a common prefix and a year-month-day date string (YYYY-MM-DD) display chronologically within a group of related documents, for instance, when viewed in a folder sorted alphanumerically by filename.
4. File and folders that are consistently named following a controlled vocabulary can easily be retrieved, sorted, and filtered according to the core criteria reflected in that vocabulary. Relevant criteria for our purposes are document type (work plan, invoice, academic article, interview, etc.) and research team / country.
5. It is helpful to distinguish between working copies of documents, draft versions that have been circulated for comments, final published versions, and revised or corrected versions of a previously published document. While word processors can embed tracked changes and comments within a draft document, it is lways useful to maintain copies of “snapshot” versions that have been published or circulated for comments – ideally in a non-editable format such as PDF –  as these revisions can more easily be referenced outside the source document itself.
6. Shared folders are most usable if they logically contain files that are related to a specific activity. The files in a given folder should relate to a single task or project, rather than a content criterion (e.g., document type), so as to facilitate the creation of ad hoc work teams and to avoid the need for team members to have access to documents distributed across multiple folders.

DFM file naming convention

File names following the DFM file naming convention are made up of three or more informational parts or tokens joined with an underscore character (_).

There should NOT be any punctuation characters in the filename; always use hyphens instead of spaces.

Minimum requirement

At minimum, a document requires the project prefix (DFM), a three-letter document code (see below), and a descriptive title. For example, the following is a minimally descriptive filename for fieldnotes conducted at Cox’s Bazar, using the code OBS for “Observational notes”:

DFM_OBS_Coxs-Bazar.docx

Creating meaningful filenames

A more meaningful filename includes additional descriptive tokens. For example, the above file could be renamed to include the author (MH) and date (2022-02-20). It could also specify a more precise locator (drying-yards):

DFM_OBS_MH_Coxs-Bazar-drying-yards_2022-02-20.docx

Abbreviations

The document title token (Coxs-Bazar-drying-yards in the example above) should have a maximum of approximately 30 characters, as some popular computer operating systems may fail to access files where the full directory path and filename exceed about 250 characters.

Abbreviations can be used in the document title if their meaning is clearly documented or otherwise apparent. For instance, the abbreviation CB-DRY could be meaningful in the example given here, if an accompanying reference document indicates that files tagged CB relate to Cox’s Bazar, and that files tagged DRY relate to fish-drying sites or activities:

DFM_OBS_MH_CB-DRY_2022-02-20.docx

Document revisions

When updating an office document (such as Word, Excel, or PowerPoint), avoid renaming the source document. Retaining a single source document on OneDrive, instead of making copies, will preserve edit history in one place.

Documents for circulation or archival should be exported to a PDF with a name that includes date, status (DRAFT, FINAL, or PUB), and revision tokens as applicable (e.g., rev01). We can take, for example, this source document:

DFM_GDL_Sample-project-guideline.docx

Successive versions of this same document could be exported to PDF for circulation as follows:

DFM_GDL_Sample-project-guideline_2020-09-04_DRAFT.pdf

DFM_GDL_Sample-project-guideline_2020-10-06_DRAFT_rev01.pdf

DFM_GDL_Sample-project-guideline_2020-10-10_FINAL.pdf

File naming tokens

The following table summarizes the tokens that should be in use.

Token	Description
General prefix (required)	DFM for documents generated by the Dried Fish Matters project. Guidelines, templates, and regulations pertaining to partner or funder organizations can be prefixed otherwise where applicable (e.g., UM, SSHRC).
Document type (required)	A code that indicates the document type (see codes below). 3 characters, upper-case.
Organization/author code (optional)	Johnson or DJ), or the acronym of an institution (e.g., VSS, CEPA). The organization code is mandatory for contracts and reports. Research documents produced within a team can be described using acronyms that identify both the team and individual contributors within it (e.g., KHM-GL for “Cambodia – Gayathri Lokuge”)
Title (required)	A filename that briefly describes the document contents. Maximum 30 characters.
Date (required for exported PDF; sometimes optional with source document)	The document release date, in YYYY-MM-DD format. The date token should always be included in the filename of a PDF exported for distribution or archival. The editable source document must also have a date string if it provides a record of activities or events on a specific date (e.g., meeting minutes, observational fieldnotes, interview). The “Modified” timestamp or document metadata cannot always be used reliably to determine the date when a document was written. The date token is optional for a document that is not date-specific, provided there is only one working version of the document.
Status (required for exported PDF; optional for source document)	DRAFT if the document is being circulated for comments and revisions, FINAL for a signed contract or similar internal document to which further updates are not expected, or PUB for a document circulated to the general public. If a status tag is used, a date should also be given. The status token should always be included in the filename of a PDF exported for distribution or archival. It may optionally be used with the source document filename.
Revision (optional)	rev”. Begin with rev01 (NOT rev1) to facilitate alphanumeric sorting (“rev11” will sort before “rev2” but after “rev02”). The revision token should always be used in combination with a status token. The revision token should be included in the filename of a PDF exported for distribution or archival.

Examples

This document is named DFM_GDL_File-naming-convention.docx. The filename consists of the following elements:

• DFM: General prefix
• GDL: Document type token, signifying “Guideline”
• File-naming-convention: Document title token

A second example might be a file named DFM_PLN_IND_Y1-work_2018-08-07_DRAFT_rev02.pdf. This is a DFM planning document related to India, setting out work in Year 1. The document draft was circulated for a third round of comments (after a second revision) on August 7, 2018. The DRAFT notation could be changed to FINAL or PUB if the document is subsequently approved for final distribution and will no longer be revised. This filename consists of the following elements:

• DFM: General prefix
• PLN: Document type token, signifying “Plan”
• IND: Organization code token, signifying “India”
• Y1-work: Document title token
• 2018-08-07: Document release date token
• DRAFT: Document status token
• rev02: Document revision token, signifying this is the second revision of the draft

Token codes for document types

These codes may be updated from time to time as project needs evolve.

Use the generic token DOC (“Document”) if nothing else fits.

Research protocols and instruments
PTC	Research protocol or instrument (questionnaire, consent form, list of procedures)
Research data
DAT	Structured dataset (database, csv file, spreadsheet, QDA file)
FIG	Figure (graphic, chart, diagram). Sketches made in the field should be classified as OBS for “Observational notes”.
IMG	Image (photograph). See separate guidance on naming and cataloguing photographs.
INT	Interview or survey responses (response sheet, audio-visual recording, notes, transcript). Structured interview or survey data combined in spreadsheet or database form should be tagged DAT for “data”.
MAP	Map or plan drawing. Sketch maps produced in the field should be classified as OBS for “Observational notes”.
MEM	Research memo or note (analytic memo, commentary, annotation)
OBS	Observational fieldnotes or recording (participant observation notes, video clip, observational sketch)
Research outputs
PUB	Publication: text intended for general, public circulation (article, book, chapter, policy brief, report) Conference presentations should be tagged PRS for “presentation” if they are primarily oral communications.
RPT	Internal report (financial report, activity report) A research report for general circulation should be tagged PUB for “publication”.
Meetings, conferences, and workshops
AGN	Meeting agenda
MIN	Minutes and notes
PRS	Presentation (slides, notes, audio or video recording, paper text, transcript) from a meeting or conference.
Working documents and operational guidelines
COR	Correspondence to and from external parties (letters, emails, newsletters). Correspondence will typically be archived within separate systems, specifically the project mailing list archive and internal mailboxes. Signed correspondence sent as email attachments, or exported copies of email messages, may be retained outside those systems for easier reference.
PER	Personnel info (contact details, banking information for wire transfers, CV, etc.)
PLN	Planning document (timeline, plan, etc.) Tag as TOR if the plan is formalized within a contract or other agreement.
TOR	Terms of Reference. This token applies to formal contracts and agreements including Transfer of Funds Agreements, Independent Contractor Agreements, and Research Sub-Agreements. The TOR will typically define payment terms, an outline of work to be undertaken, and reporting obligations.
General / internal communications (supplied by DFM Winnipeg)
GDL	Guideline (checklist, recommended procedures, protocol, etc.)
HLP	Help document (manual, tutorial, instructions). Provides information on how to access and use a database or computer software, how to submit a required report, etc.
TPL	Document template (Word document, blank form, poster template) This category is intended for project communications. Forms and templates to be used in research data collection should be tagged PTC for “protocol”.
Project management, reporting, and administration
BDG	Budget (spreadsheet, planning, or tracking document)
CLM	Claim for expense reimbursement
INV	Invoice
RCT	Receipt
TSH	Timesheet
Token codes for researchers and teams
BGL	Bangladesh
CAN	Canada
IND	India
KHM	Cambodia
LKA	Sri-Lanka
MMR	Myanmar
THA	Thailand