209 lines
6.1 KiB
Markdown
209 lines
6.1 KiB
Markdown
# ADHS-freundliches Datei- und Ablagesystem
|
||
|
||
## Die Grundstruktur
|
||
|
||
Ich würde die bestehende Struktur grundsätzlich behalten:
|
||
|
||
```text
|
||
01_INBOX
|
||
02_DEV
|
||
03_PRIVAT
|
||
04_ARBEIT
|
||
05_VAULT
|
||
99_ARCHIV
|
||
```
|
||
|
||
Dabei bekommt jeder Ordner aber eine **eindeutige Funktion**.
|
||
|
||
**01\_INBOX = noch nicht entschieden.**\
|
||
Hier landet Neues. Es darf unfertig, schlecht benannt und chaotisch sein. Die INBOX ist keine dauerhafte Arbeitsablage.
|
||
|
||
**02\_DEV = Softwareprojekte.**\
|
||
Hier bleiben vollständige Projekte inklusive Git, Quellcode, Projekt-README, projektbezogener Dokumentation usw.
|
||
|
||
**03\_PRIVAT = dauerhafte private Unterlagen.**
|
||
|
||
**04\_ARBEIT = dauerhafte Arbeitsunterlagen und Arbeitsprojekte.**
|
||
|
||
**05\_VAULT = wiederverwendbares Wissen.**\
|
||
Nicht „alles, was Markdown ist“, sondern Wissen, das unabhängig von einem einzelnen Projekt später wieder gebraucht werden kann.
|
||
|
||
**99\_ARCHIV = abgeschlossene, aber noch aufbewahrungswürdige Dinge.**\
|
||
Dubletten, temporäre Downloads und reproduzierbare Exporte werden dagegen gelöscht und nicht archiviert.
|
||
|
||
---
|
||
|
||
## Die wichtigste Änderung
|
||
|
||
Aktive Dateien müssen nicht in `01_INBOX` liegen.
|
||
|
||
Sobald klar ist:
|
||
|
||
> „Das gehört zu Café Bach“
|
||
|
||
kann die Datei beispielsweise direkt nach
|
||
|
||
```text
|
||
04_ARBEIT/Cafe_Bach/
|
||
```
|
||
|
||
Die Tatsache, dass du **gerade daran arbeitest**, wird nicht durch den Speicherort dargestellt.
|
||
|
||
Stattdessen wird der betreffende Projektordner unter Windows an **Schnellzugriff** und unter Linux/Dolphin an **Orte** angeheftet.
|
||
|
||
Damit gibt es weiterhin einen sehr schnellen Bereich „Das brauche ich gerade“, aber **keine zweite Arbeitskopie**.
|
||
|
||
Das verhindert das klassische Problem:
|
||
|
||
```text
|
||
INBOX
|
||
→ Projektordner
|
||
→ zurück INBOX
|
||
→ neuer Computer
|
||
→ Download
|
||
→ Kopie
|
||
→ Welche davon war jetzt aktuell?
|
||
```
|
||
|
||
---
|
||
|
||
## Deine Datumsbenennung
|
||
|
||
Die Idee mit
|
||
|
||
```text
|
||
YYYY-MM-DD
|
||
```
|
||
|
||
ist sehr gut und sollte bleiben.
|
||
|
||
Ich würde ein einheitliches Schema daraus machen:
|
||
|
||
```text
|
||
YYYY-MM-DD_bereich_projekt_inhalt.ext
|
||
```
|
||
|
||
Beispiele:
|
||
|
||
```text
|
||
2026-08-20_arbeit_cafe-bach_teamtreffen-protokoll.docx
|
||
2026-08-12_arbeit_sp5_programm.pdf
|
||
2026-08-07_privat_fahrzeugbrief-aufgebotsverfahren.pdf
|
||
```
|
||
|
||
Nur wenn am selben Tag mehrere relevante Versionen entstehen:
|
||
|
||
```text
|
||
2026-08-20_arbeit_cafe-bach_ablaufplan_v01.docx
|
||
2026-08-20_arbeit_cafe-bach_ablaufplan_v02.docx
|
||
```
|
||
|
||
Dadurch brauchst du **keine Tagesordner in der INBOX**.
|
||
|
||
Ein Ordner wie
|
||
|
||
```text
|
||
01_INBOX/2026-08-24/
|
||
```
|
||
|
||
liefert kaum zusätzliche Information, wenn jede Datei bereits mit `2026-08-24_...` beginnt. Gleichzeitig ist jeder Unterordner ein weiterer Klick und eine weitere Entscheidung.
|
||
|
||
Deshalb: **INBOX möglichst flach halten.**
|
||
|
||
---
|
||
|
||
## Die 3-Dateien-Regel
|
||
|
||
Die Regel ist sinnvoll, aber ich würde sie leicht verändern:
|
||
|
||
> Kategorien bekommen erst einen Unterordner, wenn ungefähr vier zusammengehörige Dateien existieren.
|
||
|
||
Für **echte Projekte** gilt diese Regel nicht.
|
||
|
||
Wenn klar ist, dass etwas ein eigenes Projekt ist, bekommt es sofort einen Projektordner.
|
||
|
||
Also beispielsweise:
|
||
|
||
```text
|
||
04_ARBEIT/Cafe_Bach/
|
||
04_ARBEIT/SP5/
|
||
04_ARBEIT/Checkpoint/
|
||
```
|
||
|
||
Innerhalb von `Cafe_Bach` musst du aber nicht sofort zwanzig Kategorien wie
|
||
|
||
```text
|
||
Protokolle/
|
||
Umfragen/
|
||
Veranstaltungen/
|
||
Social_Media/
|
||
Vorlagen/
|
||
Korrespondenz/
|
||
```
|
||
|
||
anlegen.
|
||
|
||
Erst wenn tatsächlich genug Material entsteht.
|
||
|
||
---
|
||
|
||
# Die tägliche Routine
|
||
|
||
Die Routine besteht nur aus drei Zuständen:
|
||
|
||
**Eingang → Zuhause → Archiv**
|
||
|
||
Eine neu heruntergeladene Datei darf zunächst einfach in `01_INBOX`.
|
||
|
||
Sobald du die Datei tatsächlich benutzt oder erkennst, wohin sie gehört, passiert **ein Vorgang**:
|
||
|
||
```text
|
||
Beschriften → an endgültigen Ort verschieben
|
||
```
|
||
|
||
Deinen Dokumentenbeschrifter würde ich deshalb genau an diesem Übergang verwenden.
|
||
|
||
Nicht:
|
||
|
||
> „Ich muss erstmal alles sofort ordentlich benennen.“
|
||
|
||
Sondern:
|
||
|
||
> „Diese Datei verlässt jetzt die INBOX – also bekommt sie jetzt einen Namen.“
|
||
|
||
Damit wird das Beschriften Teil einer bereits notwendigen Handlung.
|
||
|
||
Einmal pro Woche gibt es einen kurzen INBOX-Durchgang. Ziel ist nicht zwingend `0 Dateien`, sondern:
|
||
|
||
> Alles, was noch hier liegt, ist tatsächlich noch ungeklärt.
|
||
|
||
---
|
||
|
||
# Der heutige Aufräumtag
|
||
|
||
Heute würde ich ausdrücklich **nicht anfangen, hunderte Dateien einzeln umzubenennen**.
|
||
|
||
- [ ] Zuerst einen einzigen zentralen Hauptordner festlegen, der künftig die verbindliche Quelle ist. Git bleibt nur zusätzlich für `02_DEV` und `05_VAULT`; Git ist nicht das allgemeine Synchronisationssystem.
|
||
- [ ] Die bisherigen Quellen zunächst unverändert in einen temporären Importbereich übernehmen, z. B. `01_INBOX/IMPORT_2026-08-24/LAPTOP`, `ARBEITSRECHNER`, `DESKTOP`. Erst kopieren bzw. sichern, noch nichts endgültig löschen.
|
||
- [ ] Danach die offensichtlichen Doppelstrukturen beseitigen. In deinem aktuellen Bestand sind besonders `01_INBOX`, `INBOX` und `95_INBOX_laptop` Kandidaten für eine Zusammenführung. Ebenso sollten `05_vault` und `05_VAULT` nicht parallel bestehen bleiben.
|
||
- [ ] Als Nächstes komplette Pakete und Ordner sortieren, nicht deren Einzeldateien. Designpakete, Chrystal-Math-Pakete, Dashboard-Varianten und ähnliche zusammengehörige Sammlungen können jeweils als ein Objekt behandelt werden.
|
||
- [ ] Danach nur die losen Dateien bearbeiten: Privat, Arbeit, Dev, Vault, Archiv oder `UNKLAR`. Beim Einsortieren den Dokumentenbeschrifter verwenden. Was unklar ist, bleibt unklar; dafür nicht fünf Minuten recherchieren.
|
||
- [ ] Dubletten erst danach prüfen. Besonders ZIP plus entpackter Ordner, generierte `artifact-...html`-Dateien, alte Preview-Dateien und mehrfach vorhandene Projektpakete sind gute Kandidaten. Nicht alles muss ins Archiv: offensichtlicher reproduzierbarer Müll darf weg.
|
||
- [ ] Ganz am Schluss die alten INBOX-Orte leeren bzw. entfernen, aber erst nachdem geprüft wurde, dass die zentrale Sammlung vollständig ist.
|
||
|
||
## Stop-Regel für heute
|
||
|
||
Der Aufräumtag ist erfolgreich, wenn am Ende:
|
||
|
||
```text
|
||
es genau eine INBOX gibt
|
||
es genau einen VAULT gibt
|
||
jede alte Datenquelle zentral gesichert wurde
|
||
die großen offensichtlichen Blöcke einsortiert sind
|
||
```
|
||
|
||
Es ist **nicht notwendig**, dass heute jede einzelne alte Datei perfekt benannt wurde.
|
||
|
||
Perfekte Dateinamen sind Phase 2.
|
||
|
||
Eine verlässliche zentrale Ablage ist Phase 1.
|