[linux-l] Wohin mit den alten Mails? -> +sent

[Volker Grabsch]

Hallo Sven, Olaf,

vorab: ich habe nichts gegen das Tagging und finde das bei
großen Projekten/Informationsquellen auch sinnvoll. Aber nur
*innerhalb* eines solchen Projektes, und nur dann, wenn es
wirklich viele User hat.

"Globale Tags" halte ich für sinnlos, weil das eine Kategorisierung
des gesamten Webs entspricht, aus allen nur denkbaren Perspektiven
heraus.

"Private Tags", also das Tagging der eigenen Daten, finde ich
ebenfalls nicht nutzbringen. Dazu hole ich etwas weiter aus:


On Sat, Feb 10, 2007 at 08:56:49PM +0100, Sven Guckes wrote:
> > Das Kategorisieren fehlt.  Ich kann zwar einen Ordner A
> > und B anlegen, aber wenn ich eine Mail mit A un B Inhalt
> > habe, muss ich mich Entscheiden oder Kopien anlegen.
> 
> das einsortieren in folder hat einen grossen nachteil:
> damit musst du dich immer fuer einen folder entscheiden.
> und damit musst du erst einmal den richtigen folder finden.

Ich praktiziere diese Vorgehensweise und bin einigermaßen
zufrieden damit. Tagging habe ich noch nicht ernsthaft probiert,
bin aber mit folgendem recht zufrieden:

Ich wähle die Ordner nicht nach Inhalt, sondern nach Zweck,
also projektbasiert. Das gilt sowohl für Mailordner als auch
für "echte" Verzeichnisse. Jede Fotoserie, jedes Programm,
jede Vorlesung in der Uni, ist ein Projekt. Das führt zu relativ
vielen kleinen Projekten.

Oberhalb und unterhalb der Projekte gibt es relativ klare
Hierarchien, die ich möglichst flach halte:


Oberhalb der Projekte
=====================

    Work,Archive
        -> privat,öffentlich,Uni,Kunde1,Kunde2,...
            -> Projekt1,Projekt2,...
                -> ...

Eine flache Hierarchie, die ich ab und zu umordne, finde ich
praktischer als Tagging. Mit einer besseren Tool-Unterstützung
ändert sich das vielleicht, das weiß ich nicht.

Die erste Unterscheidung ist Work und Archive: In Work liegen
nur die Projekte, die ich im Moment benutze (z.B. Programme,
an denen ich arbeite) oder auf die ich in regelmäßigen Abständen
schnell zugreifen möchte (z.B. Ablage für Handy-Rechnungen).
Alles andere landet in einem Archiv-Ordner. Liegt ein Projekt auf
Eis, verschiebe ich es von Work nach Archive. Arbeite ich an einem
plötzlich wieder weiter, schiebe ich es von Archiv nach Work. Ich
finde es wichtig, diese Dinge bewusst du entscheiden. Ein Automatismus,
der mir ein lange unbenutztes Projekt nicht mehr anzeigt, wäre fatal.
Dieses billige Verzeichnis-Verschieben sowie die work/archive-
Entscheidung wird mir ein Tagging-Tool kaum abnehmen können.

Darunter gibt es Sichtbarkeitsbereiche:
* Privat     (z.B. Familienfotos, Handyrechnungen)
* Öffentlich (z.B. Freie-Software-Projekte, Webseiten)
* Uni        (z.B. Vorlesungs-Scripte)
* Kunde1     (Firmen-Aufträge für Kunde1)
* ....
Da sich diese Bereiche nicht gegenseitig ausschließen, steckt in
der Einordnung eine gewisse Willkür. An dieser Stelle könnten Tags
helfen. Andererseits wären das nichtmal 10 Tags, und außerdem schadet
es nicht, eine bewusste Entscheidung zu treffen, ob ein Projekt z.B.
der Öffentlichkeit oder Kunde1 gehört. Es zwingt mich, diese Dinge
wirklich zu trennen.

Zudem weiß ich dann, dass ich z.B. mit allem Krempel im "Kunde1"-
Verzeichnis vorsichtig sein muss, während das Zeug unter "Öffentlich"
ruhig ein effizientes unverschlüsseltes Backup auf nem Webserver
haben kann.


Unterhalb der Projekte
======================

Innerhalb eines Projektes ist die Hierarchie klar, meist ein Baum
von Programm-Code oder ein Verzeichnis mit bearbeiteten Bildern, z.B.:

    Projekt1/
        -> Katze_auf_Baum.jpg
        -> Katze_auf_Baum_Nahaufnahme.jpg
        -> Hund_in_Auto.jpg
        -> Max_Mustermann_sitzt_am_Spinnrad.jpg

    Projekt2/
        -> trunk/
            -> src/
                -> ...
            -> Makefile.am
            -> configure.ac
        -> branch-A/
            -> ...
        -> dist/
            -> build.sh
            (Freiraum zum Bauen von RPM- und Deb-Paketen)
        -> releases/
            -> 0.1
            ...

Ein einzelnes Projekt ist übersichtlich, es würde mir IMHO nicht
helfen, auf diesem Level zu taggen.

Fairerweise muss ich aber zugeben, dass ich auf eine gewisse Weise
doch tagge, indem ich mich *immer* um ordentliche Dateinamen bemühe,
insbesondere Bilder haben manchmal recht lange Namen, die beschreiben,
was interessantes auf ihnen zu sehen ist.


Suchen
======

Wenn ich mal was suche, weiß ich entweder den Projektnamen (und
damit den Projektordner) oder irgendeinen Dateinamen darin. Ein
"find" reicht meist völlig aus. Auch bei Bildern, weil ich die
wiegesagt entsprechend benenne.

Ganz selten brauch ich auch ein Grep, das aber eher innerhalb
eines Projektes.

Wenn ich wirklich suchen muss, dann weil ich etwas überhaupt
nicht mehr weiß. Das heißt, Tagging würde mir auch da IMHO nicht
helfen. Jedenfalls IMHO nicht mehr, als es die Projekt- und
Dateinamen schon tun.

Die gefundene Datei liegt dann in einem bestimmten Projekt, sodass
ich auch automatisch den ganzen "Kontext" wiederbekomme, wenn ich
das gefunden habe. Eine Suche nach weiteren (ähnlichen) Dingen entfällt
dadurch. Meistens suche ich ja keine einzelne Datei, sondern ein
bestimmtes Projekt.

Anders gesagt: Die Information, was zusammenhängt und was nicht,
steckt ja schon in der Gruppierung nach Projekten. Ich finde es
auch sinnvoll, das selbst festzulegen, zumal das durch die projekt-
orientierte Denkweise automatisch passiert. Auch hier sehe ich nicht,
wie mir ein Tagging-System zu besserer Übersicht verhilft oder
Arbeitsaufwand abnimmt.


> die zusaetzlichen zeile mit deinem kommentar
> kannst du ueber das interne kommando "edit"
> in deinem editor hinzufuegen.

Ich benutze das "edit" auch manchmal, aber nicht zum Taggen, sondern
um einen vergessenen Empfänger o.Ä. nachzutragen. Danach sende ich
die Mail nochmal mit der [b]ounce-Funktion von mutt.

Wenn ich "etwas mehr" vergessen habe, z.B. ein Attachment, dann
Verschiebe (mit [s]) ich die Mail in meinen Postponed-Ordner, und
bearbeite sie nochmal mit den Boardmitteln von mutt.

> ich wollte das immer mal als patch haben, bei
> dem man den kommentar innerhalb der oberflaeche
> von mutt hinzufuegen kann - oder editor aufruf.
> ein solcher patch existiert auch - aber dieser
> hat es leider nie in den main source geschafft.
> 
> anscheinend gibt es nicht genuegend leute, die
> eine kommentarfunktion im mailer brauchen.. ;)

Ich auch nicht. Ich habe auch für Mails sowas wie Projektordner,
und schiebe sie beim Speichern an die entsprechende Stelle. Das
heißt, wenn ich glaube, eine Info nochmal gebrauchen zu können,
schiebe ich die Mail / den Thread in den zugehörigen Projektordner
von dem Projekt, bei dem ich mich mit diesem Thema beschäftige.

Tags bräuchte ich daher nur, wenn ich *nicht* weiß, wofür ich das
später gebrauchen kann. Aber kann man unter diesen Voraussetzungen
vernünftige Tags definieren? Landet man in diesen Fällen letztendlich
nicht doch wieder bei der Volltextsuche, wo die Tags höchstens eine
kleine helfende Funktion bei den Suchbegriffen darstellen?


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR