File Organisation & Naming
Version 6.2 by Veronika Kocher on Friday, 04 Sep 2026 14:23
.fon{max-width:1400px;margin:0 auto;color:#322f2b}
.fon *{box-sizing:border-box}
.fon-card{border:1px solid #e3ded6;border-radius:11px;background:#fcfbf8;box-shadow:0 1px 3px rgba(0,0,0,.035)}
.fon-hero{height:132px;overflow:hidden;background:#f1eee9;border-radius:11px 11px 0 0}
.fon-hero img{width:100%;height:100%;object-fit:cover;object-position:center 45%;display:block}
.fon-eye{font-size:12px;font-weight:700;letter-spacing:.075em;text-transform:uppercase}
.fon-sec{margin:0 0 27px 0}
.fon-sec h3{font-size:22px;line-height:1.25;margin:0 0 7px;color:#35312d;text-align:left!important;text-align-last:left!important;text-justify:auto!important;word-spacing:normal!important}
.fon-sec>p{color:#625d56;line-height:1.58;margin:0 0 13px}
.fon-grid{display:grid;grid-template-columns:repeat(auto-fit,minmax(285px,1fr));gap:12px}
.fon-grid-2{display:grid;grid-template-columns:repeat(2,minmax(300px,1fr));gap:12px}
.fon-info{padding:15px 17px;border:1px solid #c7e5ed;border-left:5px solid #21b6d7;background:#eaf6f9;border-radius:8px;color:#365e68;line-height:1.5}
.fon-info strong{color:#2d5661}
.fon-plan{padding:15px 17px;border:1px solid #efd9cc;border-left:5px solid #e94b13;background:#fff6f1;border-radius:8px;color:#67564e;line-height:1.5}
.fon-plan strong{color:#744531}
.fon-warn{padding:15px 17px;border:1px solid #efd9cc;border-left:5px solid #e94b13;background:#fff6f1;border-radius:8px;color:#67564e;line-height:1.5}
.fon-warn strong{color:#744531}
.fon-check{position:relative;padding:12px 13px 12px 37px;border:1px solid #e3ded6;border-radius:8px;background:#fffdf9;color:#504a44;line-height:1.5}
.fon-check:before{content:"✓";position:absolute;left:13px;top:10px;color:#e94b13;font-weight:800}
.fon-step{position:relative;padding:13px 14px 13px 50px;border:1px solid #e3ded6;border-radius:8px;background:#fcfbf8;min-height:76px}
.fon-step .n{position:absolute;left:13px;top:13px;width:26px;height:26px;border-radius:50%;display:flex;align-items:center;justify-content:center;background:#f7e6dd;color:#7b4430;font-weight:800;font-size:12px}
.fon-step h4{margin:0 0 4px;font-size:16px;line-height:1.3;color:#3b352e;text-align:left!important;text-align-last:left!important;text-justify:auto!important;word-spacing:normal!important}
.fon-step p{margin:0;color:#625d56;line-height:1.45}
.fon-example{padding:14px 15px;border:1px solid #e3ded6;border-top:4px solid #e94b13;border-radius:9px;background:#fcfbf8}
.fon-example h4{margin:0 0 6px;font-size:16px;color:#3e372e;text-align:left!important;word-spacing:normal!important}
.fon-example p{margin:0;color:#625d56;line-height:1.5}
.fon-code{margin-top:8px;padding:9px 10px;border:1px solid #e3ded6;border-radius:6px;background:#f7f4ef;color:#49433d;font-family:ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;font-size:12px;line-height:1.45;overflow-wrap:anywhere}
.fon-table-wrap{overflow-x:auto;border:1px solid #e3ded6;border-radius:8px}
.fon-table{width:100%;border-collapse:collapse;background:#fffdf9;min-width:900px}
.fon-table th,.fon-table td{padding:10px 11px;border-bottom:1px solid #e3ded6;vertical-align:top;text-align:left;line-height:1.4}
.fon-table th{background:#f3efe8;color:#403b36;font-weight:700}
.fon-table tr:last-child td{border-bottom:0}
.fon-service-grid{display:grid;grid-template-columns:repeat(auto-fit,minmax(260px,1fr));gap:10px}
.fon-service{display:block;padding:13px 14px;border:1px solid #e3ded6;border-left:4px solid #e94b13;border-radius:8px;background:#fcfbf8;color:#2f2b27}
.fon-service strong{display:block;margin-bottom:4px}
.fon-service span{display:block;color:#625d56;line-height:1.45;font-weight:400}
.fon-linkgrid{display:grid;grid-template-columns:repeat(auto-fit,minmax(260px,1fr));gap:8px}
.fon-navlink{display:block;padding:10px 11px;border:1px solid #e9e4dc;border-left:3px solid #e94b13;border-radius:6px;background:#fffdf9;color:#252321;text-decoration:none;font-weight:600;line-height:1.35}
.fon-navlink:hover,.fon-navlink:focus{background:#fff7f1;text-decoration:none}
.fon-resource-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px}
.fon-resource{padding:15px 16px;background:#fcfbf8;border:1px solid #e3ded6;border-radius:9px}
.fon-resource strong{display:block;color:#4c4130;margin-bottom:4px}
.fon-badge{display:inline-block;margin:5px 0 7px;padding:4px 8px;border-radius:14px;background:#fff4ee;border:1px solid #efd9cc;color:#8a4d36;font-size:11px;font-weight:700;letter-spacing:.055em;line-height:1.2}
.fon h1,.fon h2,.fon h3,.fon h4,.fon h5,.fon h6,.fon h1 a,.fon h2 a,.fon h3 a,.fon h4 a,.fon h5 a,.fon h6 a{text-align:left!important;text-align-last:left!important;text-justify:auto!important;word-spacing:normal!important}
@media(max-width:850px){.fon-grid-2,.fon-resource-grid{grid-template-columns:1fr}}
@media(max-width:680px){.fon-hero{height:105px}.fon-sec h3{font-size:20px}}
Start with a shared minimum.
Decide how folders are structured, which elements belong in file names,
how working, approved and master versions are distinguished, and where these rules are documented.
The structure should support project work — not create extra bureaucracy.
Use only the information in folders and file names that actually helps people understand, distinguish and find files again.
STEP 1 · DEFINE THE PROJECT STRUCTURE
Organise files by project function and content, not by individual people
A good structure remains understandable when people change roles or the project is handed over to someone else.
Project administration: Keep contracts, budgets, funder documents, reports and administrative records separate from research or production material.
Working material: Organise active files by clear project areas, work packages, media or methods.
Source material: Keep originals, incoming files or unchanged source material visibly distinct from edited files.
Process documentation: Keep sketches, logs, production documents, provenance and methodological records findable.
Master files: Keep authoritative or approved versions clearly separate from working and export copies.
Outputs: Distinguish publication, presentation and handover versions from internal working files.
External contributions: Store material from partners or third parties so that origin and rights information remain traceable.
Archive / closure: Decide early what should be retained, preserved, deposited or deleted at the end of the project.
KEY DISTINCTIONS
These terms should not be mixed up in project work
Working file ≠ master file.
A file can be convenient for day-to-day editing without being the authoritative or preservation-suitable version.
A file can be convenient for day-to-day editing without being the authoritative or preservation-suitable version.
Latest ≠ approved.
The most recently edited file is not automatically the version that should be confirmed, published or handed over.
The most recently edited file is not automatically the version that should be confirmed, published or handed over.
Folder name ≠ complete documentation.
Folder structure helps orientation but does not replace metadata, provenance or decision records.
Folder structure helps orientation but does not replace metadata, provenance or decision records.
Synchronisation ≠ version control.
A synchronised folder does not automatically show which version is authoritative or why a change was made.
A synchronised folder does not automatically show which version is authoritative or why a change was made.
Export ≠ master.
PDF, JPEG, MP4 or other distribution formats can be practical outputs while other files remain authoritative for editing or preservation.
PDF, JPEG, MP4 or other distribution formats can be practical outputs while other files remain authoritative for editing or preservation.
Personal folder ≠ project structure.
Project files should not depend on individual people's names if they need to remain understandable and reusable by the team.
Project files should not depend on individual people's names if they need to remain understandable and reusable by the team.
STEP 2 · DEFINE A FILE-NAMING CONVENTION
File names should make relevant differences visible
Use a consistent pattern and only the components that are genuinely useful for your project.
01
Choose the core elements
For example project code, content, date, version, language, status or responsible project area.
02
Define the order
Choose an order that works for sorting and quick reading.
03
Use dates consistently
If dates matter, use a consistent format such as YYYY-MM-DD.
04
Make versions visible
Use clear version numbers when several working states exist in parallel or sequence.
05
Keep status labels simple
Use a small set of understandable status labels and avoid chains such as final_final_new_reallyfinal.
06
Use special characters deliberately
Keep file names robust and compatible with the systems and exchange routes you actually use.
07
Document the convention
Keep a short example or README file in the project so everyone follows the same convention.
08
Test the convention
Use real files to check whether names are readable, sortable and understandable to new team members.
EXAMPLES
A pattern is useful when it reflects the actual work
Project file with date and version
Useful when chronology and version state matter.
PROJ_interview-guide_2026-09-03_v03.docx
Media production with status
Useful when several editing and output states need to be distinguished.
PROJ_film-trailer_v07_APPROVED.mov
Multilingual publication
Useful when language versions are managed in parallel.
PROJ_catalogue-text_EN_v04.docx
Dataset or structured export
Useful when content, period or release needs to be distinguished.
PROJ_dataset_2026-09_release-01.csv
Distinguish master and derivative
Master file and presentation copy should be unambiguous.
PROJ_installation_MASTER_v02.tif
PROJ_installation_web_v02.jpg
PROJ_installation_web_v02.jpg
Process documentation
For artistic processes, context can be as important as the final output.
PROJ_rehearsal-notes_2026-09-03_AB.md
STEP 3 · DOCUMENT A MINIMUM STANDARD
A short standard is enough if it is used consistently
Keep the rules in one central place that everyone can access — for example in a README file or the project documentation.
| Element | What to define | Example |
|---|---|---|
| Folder structure | Which top-level folders exist and what is each one for? | 01_Admin · 02_Working · 03_Source · 04_Master · 05_Output |
| File names | Which components are required and in what order? | Project_Content_Date_Version |
| Date | Which format is used? | YYYY-MM-DD |
| Version | How are working states numbered? | v01, v02, v03 |
| Status | Which small set of status labels is used? | DRAFT · REVIEW · APPROVED · PUBLISHED |
| Master | How is the authoritative version identified? | MASTER or a documented master folder |
| Responsibility | Who maintains the convention and decides on exceptions? | Project team / defined role |
| Review | When is the structure checked again? | Project start, milestone, team change, handover |
STOP & CHECK
Common warning signs in file and folder organisation
Several files are called "final".
It is unclear which version is actually approved, published or intended as the master.
It is unclear which version is actually approved, published or intended as the master.
Folders are named after people rather than project functions.
The structure becomes hard to understand when roles change or the project is handed over.
The structure becomes hard to understand when roles change or the project is handed over.
File names contain no distinguishing information.
Content, date, version or status can only be identified by opening the file.
Content, date, version or status can only be identified by opening the file.
Everyone uses their own rules.
The shared storage area no longer functions as a common project structure.
The shared storage area no longer functions as a common project structure.
Master files and exports sit side by side without clear labels.
It is unclear which file should be edited further or preserved for the long term.
It is unclear which file should be edited further or preserved for the long term.
The convention exists only in one person's head.
Without brief documentation, it cannot be continued reliably during absence, staff changes or project closure.
Without brief documentation, it cannot be continued reliably during absence, staff changes or project closure.
SERVICES & SUPPORT
Who can support file and documentation practice
Project team
Owns the shared working convention and decides which structure is practical for the specific project.
University Library / Research Data Management
Advises on research-data, documentation and data-management practice where files are part of a research-data or DMP context.
IT
Supports technical implementation where storage locations, access models or tools are involved.
Support Kunst und Forschung (SKF)
Connects file and documentation requirements in funded projects with proposals, deliverables or the Data Management Plan.
RELATED TOPICS
File and folder organisation is closely connected to these decisions
PRACTICAL RESOURCES
Info sheets, tutorials and templates
Info SheetsCOMING SOON
Short guidance on folder structures, file naming and basic versioning.
TutorialsCOMING SOON
Step-by-step examples for project structures, naming conventions and master files.
Checklists & TemplatesCOMING SOON
README template, naming scheme and project-handover checklist.
Need help defining a suitable minimum standard?
Start with one short shared rule for folders, file names, versions and master files.
For research-data or DMP requirements, the University Library / Research Data Management can advise;
for funded projects, SKF can connect those requirements to the project route.
Search terms & related topics
file organisation · file organization · file naming · folder structure · file structure · naming convention · filename · filenames · versioning · version number · master file · working file · approval · final · README · project folder · project files · research data · documentation · provenance · handover · archiving · file format · file management