Versionschaos: Ein Dateiname ist kein Protokoll.

Ein Dateiname bekommt eine Aufgabe, die er nicht tragen kann

Namenskonventionen sind die übliche Verteidigung gegen Versionschaos, und sie scheitern vorhersehbar. Eine Konvention hält, solange eine Person sie anwendet. Sie wird mit jeder weiteren Person schwächer. Sie bricht an dem Tag, an dem sie etwas ausdrücken soll, wofür sie kein Feld hat.

final_v2 sagt, dass etwas Neueres als v1 existiert. Es sagt nicht, was sich geändert hat, ob die Änderung freigegeben wurde oder ob v2 v1 überall dort ersetzt hat, wo v1 bereits im Einsatz war. final_v3_FINAL sagt, dass jemand das Vertrauen in die Konvention selbst verloren hat. Jeder Unterstrich ist ein Behelf für eine Tatsache, die der Name nicht speichern kann.

Ein Name ist ein Etikett. Was das Team tatsächlich braucht, ist ein Protokoll.

Kopien sind die Antwort des Speichers auf Kontext

In einer ordnerbasierten Bibliothek ist eine Kopie der einzige Weg, ein Asset an zwei Orte zu legen. Gehört ein Bild in einen Kampagnenordner, einen Partnerordner und ein Archiv, antwortet der Speicher mit drei Dateien. Von diesem Moment an verändern sich die drei getrennt. Eine Retusche landet in der einen. Ein Zuschnitt wird in der anderen angepasst. Die dritte bleibt unberührt.

Die Bibliothek hält jetzt drei Versionen eines Bildes, und nichts in der Struktur sagt, welche aktuell ist. Die Duplikate waren keine Nachlässigkeit. Sie waren der einzige verfügbare Mechanismus, um auszudrücken, dass ein Asset mehr als einen Kontext hat.

Die Rechnung wächst rasch. Eine Kampagne, die 40 ausgewählte Bilder durch drei Korrekturrunden führt, produziert weit über hundert Dateien, bevor eine einzige Kopie für einen zweiten Ordner entsteht. Mit den Kopien hält die Bibliothek mehrere hundert Dateien, die 40 Assets darstellen. Für das Dateisystem sieht jede davon gleich gültig aus.

Die Kosten zeigen sich als Nacharbeit und falsche Versionen

Die sichtbaren Kosten von Versionschaos sind das Prüfen. Jemand öffnet zwei Dateien nebeneinander, um den Unterschied zu finden. Jemand fragt im Channel, welche aktuell ist. Jemand exportiert eine Version neu, statt den vorhandenen zu trauen. Jede Prüfung ist klein. Über eine arbeitende Bibliothek hinweg wird das Prüfen zu einer eigenen Aufgabe.

Die grösseren Kosten sind leiser. Ein veraltetes Bild läuft in einer aktiven Kampagne. Ein überholter Zuschnitt geht an einen Partner. Ein Druckauftrag verwendet eine Datei, die zwei Wochen zuvor ersetzt wurde. Nichts hat die ältere Datei als ersetzt markiert, also stand nichts zwischen ihr und der Verwendung.

In den meisten Teams ist die Rückfallebene eine Person. Sie wird zur Instanz dafür, welche Version aktuell ist, und die Bibliothek funktioniert nur, wenn diese Person verfügbar ist. Der Stand der Assets existiert – als institutionelles Gedächtnis, nicht als Struktur.

Die Entscheidung fällt dort, wo die Datei sie nicht festhalten kann

Jede finale Version wurde durch eine Entscheidung final. Jemand hat geprüft, verglichen und gewählt. Dieser Moment ist real, und er findet fast immer abseits der Datei statt – in einem Review-Call, einem Thread, einem Meeting. Die Datei wird danach umbenannt, oder auch nicht.

Von da an driften Datei und Entscheidung auseinander. Die Entscheidung lebt in einem Thread, der ausser Reichweite scrollt. Die Datei liegt in einem Ordner und trägt nur ihren Namen. Fragt später jemand, was entschieden wurde, muss die Antwort aus Nachrichten, Calls und Erinnerung rekonstruiert werden. Eine Entscheidung, die nicht an der Arbeit festgehalten ist, muss aus allem darum herum wieder aufgebaut werden.

Darum ist auch die neueste Datei keine sichere Antwort. Nach Datum zu sortieren findet die jüngste Version, nicht die entschiedene. Ein spätes Experiment, eine nicht freigegebene Retusche oder ein Export für einen bestimmten Kanal können alle neuer sein als die Version, die Kund:innen bestätigt haben. Die Version, die zählt, ist nicht die neueste Datei. Es ist die, über die entschieden wurde – und in den meisten Bibliotheken ist diese Entscheidung nirgends festgehalten, wo die Datei sie zeigen könnte.

Der Stand gehört ans Asset, nicht in den Namen

Versionschaos ist das sichtbare Symptom von Stand, der am falschen Ort gespeichert ist. Die instinktive Antwort ist strengere Benennung. Die strukturelle Antwort ist eine andere: Das Asset selbst trägt seinen Stand, und das System hält ihn fest.

Dieser Standard hat drei Teile. Der Status ist am Asset festgehalten, also sind aktuell und ersetzt Tatsachen, keine Vermutungen. Ein Asset kann in mehreren Kontexten erscheinen, ohne kopiert zu werden, also gibt es nichts, das auseinanderlaufen kann. Eigenschaften sind durchsuchbar, also ist das Finden der freigegebenen Version eine Suche, kein Erinnerungsakt.

moodcase Visual Asset Management ist ein Beispiel für diesen Standard. In den Team-Plänen halten Workflow-Status fest, wo ein Asset steht, Kollektionen zeigen ein Asset in mehreren Kontexten ohne Duplikate, und Metadaten machen die aktuelle Version über ihre Beschreibung auffindbar. Der Name kann wieder ein Name sein.

Nichts davon verlangt mehr Disziplin als eine Namenskonvention. Es verlangt, dass die Disziplin in der Struktur lebt statt im Dateinamen.