From: Boris Kraut Organization: Date: Sat, 21 Jul 2012 01:55:20 +0200 Category: Message-ID: <20120720235520.kMMlC8@silberbruch> Keywords: Comments: To: undisclosed-recipients: ; Subject: Taskmanagement (was: Statusbericht SSD und OS-Wechsel) Hier noch der vorlaeufig letzte Teil einer wieder etwas technischer angehauchten Reihe. Ueber die verschiedenen Taskmanagement- und TODO-List-Techniken habe ich schonmal geschrieben und dabei auch erwaehnt, dass ich am Ende doch wieder bei eMails gelandet bin. Wahrscheinlich habe ich auch schon angemerkt, dass fuer die meisten Faelle taskwarrior o.ae. genau das ist, was man haben will. Und trotzdem habe ich die kleinen Minuten der Ruhe in den letzten Tagen auch fuer die Erneuerung der Shell-Skripte fuer meine eigene Task- Management-Loesung genutzt -- insbesondere: 1) to_maildir: Zum Testen fand ich es nuetzlich die Einlieferung von Tasks/Mails auch unter meiner Kontrolle zu haben. Das frueher dafuer verwendete Ruby-Skript war zwar deutlich leistungsstaerker, aber brachte eben Ruby als Abhaengigkeit mit; nicht unbedingt das was ich unter leichtgewichtig verstehe. Als Ersatz dafuer habe ich to_maildir geschrieben, was fuer ein Shellskript doch relativ konform mit dem "Standard" geht. 2) add_task: Wenn ich schon Aufgaben als Mails speichere, wollte ich zumindest so weit es geht auf vorhandene Kon- ventionen und Standards bauen. Wie ich schon oft beklagt habe, gibt es eine Fuelle von Mailheadern, die einem echt das Leben erleichtern koennten, aber von nahezu keinem MUA genutzt werden. Mit add_task kann ich schnell Taks hinzufuegen und die entsprechenden Header setzen. Es ersetzt quasi Taskwarriors 'add' Befehl auf der einen Seite, auf der anderen Seite kann man es als 'anno' fuer Arme ansehen. Anno ist ein gutes Stichwort, denn idR lege nicht ich den kompletten Task an, sondern ich bekomme eine Mail von aussen, die ich dann eben als Task markieren, also die entsprechenden Header hinzufuegen/aendern/annotieren moechte: - Importance, Priority, X-Priority (Prioritaet) - Expires, Reply-By (missbraucht als Deadline) - Keywords (Tags; ggf. mit Taskwarrior-Kuerzeln) - Comments (kurz; laengere Beschreibungen im Body) - Organization (ggf. anfragende Organisation, Auftragsteller, ...) - Message-ID (wie ueblich) - Status (derzeit nicht verwendet; Status wird in Maildir-Flags gesetzt; evtl. zusaetzlich hier speichern, um nicht nur Maildir bedienen zu koennen.) Einige der Header sind nicht mehr ueblich oder gar standardisiert, sondern stamen aus X.400 und wurden nur zur Vereinfachung des Datenaustauschs genutzt. So weit tut das alles und die wichtigen Funktionen sind auch schnell in den MUA der Wahl gehackt, aber da ist noch viel Luft nach oben. Ich muss noch sehen, welcher MUA sich fuer besonders passend fuer den Umgang mit solchen Termin/Task-Mails herausstellt bzw. wie viel ich da ggf. nacharbeiten muss. Kann auch gut sein, dass das Nach- arbeiten zu viel Aufwand ist und ich schneller einen kleinen Viewer geschrieben habe... aber MUAs machen ja schon so viel richtig, dass es unsinnig waere, da was eigenes zu haben -- genau deswegen wollte ich ja Taks als Mails haben. Wenn ich jetzt solche Gedanken habe, muss evtl. mutt selbst mal dran glauben.. schade, dass es kein Mail- dir-MMH gibt... Zweiter Punkt auf meiner Liste waere noch eine Reminder-Faehigkeit, aber das sollte mit at und cron nicht sondelrich schwer werden. Ich denke ich lasse at/cron einfach je nach gewuenschte Vorlauf Zeit Erinnerungsmails verschicken (die dann nicht als Tasks auflaufen, sondern in der normalen Inbox landen. Wobei ich das nicht so wichtig finde, nen gut eingestellter MUA/Viewer sollte so was eigentlich ueberfluessig machen.