Development teams will often use a Kanban board to track the status of various tasks. Tasks get initially assigned to an starting point (usually the "Backlog" or "Ideas" column) and progress through other stages until they reach completion. These stages commonly include

Backlog/Ideas

Tasks start here as a way to keep track of their mere existence

Todo/In Process

In each iteration tasks move from the "Backlog" to the "Todo"/"In Process" status for active progress.

Review/Testing

Upon completing a "Todo"/"In Process" task, it would likely move to the "Review"/"Testing" column

Done

If all tests/reviews pass, it moves to this column.

Other optional columns might distinguish "Backlog" items as "Ideas" vs. "Bugs" vs. "New Features". Or the "Review"/"Done" columns might have more granularity, offering "Testing", "Deployed", and "Delivered" columns. To help keep the "Done" column more useful, older tasks might move to an "Archive" column. We'll stick with the initial four columns listed above.

Notice that each Kanban column holds a collection of items. Much like a subdirectory, or an archive file. This means it doesn't take much to effectively turn mail-folders into a Kanban board. Additionally, you can keep those mail-folders inside a git code repository to keep your project status in sync between various machines. Traditionally, these get laid out as columns with tasks moving from left to right as they progress. However, the value comes from the organization into categories, not the visual presentation in columns.

Implementation Basics

For this, we'll use mail folders to hold messages, each containing relevant task information.

Mail-store formats

Most local mail programs (MUAs) support one of two common mail-store formats:

mbox

This older format holds a folder's mail in a single plain-text file. While just about every mail program supports mbox format, it has certain issues:

• if multiple programs access the mbox file, they need to lock it which may not work on network file systems
• standards for escaping vary, so one program might cause corruption (usually involving escaping of From lines and the escaping of already-escaped lines)
• mailbox corruption or truncation can lose all the mail it contains
• if kept in version-control repository like git, it's more likely that you'll encounter conflicts when merging

Maildir

This more recent format has support of most MUAs except the venerarble mail(1) and addresses all of the issues with mbox

For this post, we'll use mbox files because they work with mail(1), which exists on pretty much every Linux, MacOS, and BSD machine by default. Then after walking through that, I'll include details on doing similarly with mutt(1)/neomutt(1) which supports Maildir format.

Using mail(1)

By default mail(1) reads its configuration from ~/.mailrc issuing each of the commands such as setting options. If you only have one project in play, you can put configuration in there. Alternatively, you can specify the location of a configuration file at startup via the $MAILRC environment variable. Most importantly, we'll use a custom mailrc file that points to the kanban/ folder in our project, enabling folder-relative shortcuts:

$ cd ${PROJECT_DIR}
$ mkdir kanban
$ for c in backlog inprocess testing done; do touch kanban/$c ; git add kanban/$f ; done
$ git commit -m "Add Kanban mbox files"
$ echo set folder="${PROJECT_DIR}/kanban" > mailrc

With this set up, we can now create new entries via mail (assuming your local MTA or MDA works to deliver mail locally):

$ mail -s "Fix spelling in man-page" $USER

That message could go to a mailing-list for review by others instead of the local user or just get locally delivered.

Using mutt(1)/neomutt(1)