Anyone using Procmail to manage email next actions?

[Suziloo]

Most of my work requests come throught email and I find managing the tasks daunting. Have tried setting up folders both digital (in email client) and paper and neither seems to be working for me.

I'm thinking that I could use procmail to dump incoming emails into a database (preferably Postgres) and use a web-based interface to process the new stuff and also choose next actions to perform on the already processed stuff.

I could set up all this on my own, but I'd prefer to not reinvent the wheel if there is already a solution out there.

Is there anyone out there already using this sort of setup that is working well in a GTD workflow?

 

[craigm]

Might not want to do this, and here's why

I'm assuming these are ticket type requests, so if they're a little different, perhaps this won't work.

I'm currently using procmail to manage my mailing lists, and one list that I have is generated by the program rss2email. I have those mails dumped into a folder.

How is this similar to your situation? Well, it's a lot of mail, and I feel like I have to sift through it like it's another inbox.

The truth is, even if you dump all of those mails into a database, you're still going to have to deal with each and every one of them, and you're going to add the compexity of a database on top of what are just simple e-mails.

I'd recommend rather than getting too fancy with popping the notes into a database or a new folder that you seriously think about what the next actions on each of these e-mails is. Are they each tasks that need to be addressed in turn? If they are, you should treat that communication just as you would any other e-mail requesting your attention. That means determining if it can be completed in less than 2 minutes or if it is actionable, then you need to treat it just like your other actions.

Now, that said, I treat my RSS feeds like read/review, so I have a luxury to ignore them and delete lot of them that I don't find interesting in the moment. And in your e-mail client, if you get a lot of uninteresting or non-actionable material, just delete it.

One recommendation that the GTD Fast CDs has is to create an @Actionable folder for those mails that require action, but will take longer than 2 minutes. I'd caution against this, as it then becomes yet another bucket to check, and you will likely not check it if you get lots of mails. I'd also caution against just stuffing your ticket mail in here without processing it, as you'll dillute your actionable and non-actionable mails.

Hope this helps. I know it's not what you're looking for exactly, but hopefully it'll give you some fodder for thinking about what it is you're trying to accomplish here.

 

[Suziloo]

I work better with databases

My intention is to have all my emails processed so that I can go to the database at predefined times and "empty in" in the same manner that one proceeds with GTD.

At all other times, I will be working on NAs that I've already identified. My reasons for wanting to do this via procmail/browser are:

1. i'm comfortable with it.
2. i prefer *nix solutions to windows
3. various paper/electronic solutions (including my palm) haven't been successful
4. i almost always have a browser open. if i set my home page to my new system, my NAs will be easy to access as i move from one task to another and hopefully will keep me on track with what needs to be done.

 

[craigm]

Still advising caution

I'm still advising caution in using this system for several reasons:

1) If they're already in a ticketing system, then the ticket system has the latest information, and generally has some way of sorting out this information without you having to do much. Some even have the ability to use some form of macro capability so you can further customize it for your needs. Also, if your mail includes updated versions of these tickets, will you be updating your copy?

2) These tickets are most likely not next actions, so sorting them in a database is just going to give you a sorted mass of items that need completion, not do-able next actions. Are you planning on inserting next action steps into this database as well?

3) Does the e-mail contain all of the text that you require, or will you spend your time trying to gather all of the required fields?

4) Are you going to put the entire text of the mail into a BLOB, or are you going to take the effort to parse out the mail into individual fields? If you are going to make the BLOBs, is your database able to search those BLOBs quickly and efficiently?

5) You mention that you're looking for a *nix solution. Are both the ticket tracking and mail systems using Windows, or are there *nix alternatives for accessing both that don't suck? (I know that sometimes the *nix clients of software are very crippled when compared to the Windows version).

6) Is there an API you might be able to use instead to garner information from the ticket system, rather than using mail as the protocol? Mail is terribly unreliable, and if an alternative exists, you may want to explore it.

It's simple to think "Well, I'll just stuff it all into a database, since I can retrieve it all from a database", but even the most skilled SQL jockeys will require some structure to make sense out of the data going into the database. Are you prepared to care and feed for an additional system in case something changes upstream? Creating systems takes planning, and the quick 1 hour hack you do today could become the 4-8 hour maintenance headache later on.

The most important part about all of this, outside of the technical questions, is that you end up with a list of next actions to complete these tasks. Without them, you will have moved your mail spool of undoable mail into a database of undoable rows. How do you plan to seperate next actions so that you'll see them when you need to see them, and can create them quickly in under 30 seconds. If it's not that quick, you're not going to be using your system effectively, and you'll likely leave your entire pile of mails in the database as your next action list. That's not going to solve any problem you might have.

That said, if you're still interested in doing this, I will do my best to help out. Please understand my reasons for not posting posting solutions thus far are because I can see several pitfalls with this approach (I've thought about them myself, and I've used several systems that seemed like they were effective at the time, and have proved otherwise).

Hope this helps!

 

[LeonGTD]

I am using Sieve to manage some of my workflow - by filtering different people or their companies into different contexts.

I have tried to filter by using context to different web folders in IMAP, but it does not work too well. It is not smart enough to put in @Wait or @Reply for example.

Now I have created an email system for myself and it works okay. The only catch is I am filtering those important emails shown in INBOX to contexts. As I have filter all all unimportant emails, spending a brief time to read them is okay.

To your case, if you are receiving specific work requests, you should really use a ticketing system instead of just email. Check out Request Tracker (A ticketing solution written in Perl - http://www.bestpractical.com/rt/ ) which you can link email to this system. Anyone can send a request through email and you can manage it through email or web interface.

Hope it helps.

Most of my work requests come throught email and I find managing the tasks daunting. Have tried setting up folders both digital (in email client) and paper and neither seems to be working for me.

I'm thinking that I could use procmail to dump incoming emails into a database (preferably Postgres) and use a web-based interface to process the new stuff and also choose next actions to perform on the already processed stuff.

I could set up all this on my own, but I'd prefer to not reinvent the wheel if there is already a solution out there.

Is there anyone out there already using this sort of setup that is working well in a GTD workflow?

 

[Suziloo]

No ticketing system in place

1) If they're already in a ticketing system, then the ticket system has the latest information, and generally has some way of sorting out this information without you having to do much. Some even have the ability to use some form of macro capability so you can further customize it for your needs. Also, if your mail includes updated versions of these tickets, will you be updating your copy?

i am not using a ticketing system. considered it, but haven't come to a decision because i'm not sure if i can get my customers to use one. also not sure if i want my customers to experience the impersonal nature of such systems.

i am an 'sql jockey', technology is not the issue... i want to parse out the email headers, enter info in my new "inbox" and then be able to access my inbox to assign NAs and contexts to items. anything that's been processed this way is no longer in my inbox, i can then go to my contexts and start working on NAS.

perferably, i'd also be able to add items that come in through phone/voicemail, etc.

eventually, i'd like to be able to extend this sytem so everything is in one place. currently, i use sciral for tasks that should occur within a date range, palm to-do for items that have to occur (or recur) on a specific date. in a perfect world, i'll be able to use the system to track the time i spend on billable work & import into my billing system.

i'm just wondering if there are people out there who use a *nix system that is designed for or works well with GTD.