Using Fastmail email rules and labels to triage GitHub notifications
A very specific workflow that just might be useful to you..
I’ve got a email workflow for managing my GitHub notifications that I quite like and thought I’d share it, but it’s probably quite specific to the exact services that I use, but maybe it’ll help or inspire someone.
I get a lot of emails from GitHub, approximately 450 distinct email threads in the last 30 days. I much prefer using my email to keep track of issues I’m assigned to, or pull requests that I need to review, than using the web interface in GitHub. I also want to subscribe to repositories like rust-lang/rfcs to keep on top of everything going on. That’s a lot of notifications, so I’ve landed on a elaborate system of labels, email rules and saved searches that makes it easy to catch up on my notifications at-a-glance and filter out the notifications which don’t require my input.
A bunch of this is probably replicable in email platforms other than Fastmail, but I don’t know, your experience may vary.
In the screenshot below, you can see what I’ve ended up with:
My goal with this system was to make it easy at a glance to get a sense for whether something required my input (and filter on that), and be able to prioritise quickly. I make these decisions based on a couple things - the project notifying me (notifications from rust-lang/rust will get looked at quicker than notifications from rust-lang/rust-forge), and the nature of the notification (issues/pull requests that I’m assigned to are higher priority than a mention which is higher priority than a team mention which is higher priority than a repo I’m a subscribed to, for example).
Fastmail supports organising your email using both folders and labels. Labels are more useful for my workflow because I can apply multiple labels to an email, which is necessary to be able to add all the labels that I need in order to organise notifications based on the project and notification kind. Labels are applied to individual emails, and conversations (an email thread) show all of the labels applied to the emails in the conversation.
So that I can see why I got an email from GitHub, and can prioritise it, I create a tree of labels matching the kinds of notifications that I can identify from GitHub’s email headers:
Each of these labels have a corresponding mail rule, which always fall-through to the next rule (and so are ordered before all the rules that don’t fall-through).
The root label for GitHub notifications is GH (it’s only not GitHub because more labels are visible in the message list with the shorter name), which just checks for notification email from GitHub:
For almost all of the notification kinds, the rule just checks the X-GitHub-Reason header (relevant GitHub documentation):
The only rule that doesn’t follow that pattern is checking whether something is merged, as GitHub don’t have a X-GitHub-Reason value for that. Instead, I use a regular expression on the email body1 and check for the existence of a X-GitHub-Reason header:
Labels for tracking which project a notification came from follow a similar structure:
I don’t create labels for every project, just common ones. I mostly do this because I get some emails from projects which aren’t Rust and it’s nice to differentiate those at a glance.
Like GitHub labels, each of these correspond to a fall-through mail rule:
Each of these rules check for mailing list ids (or some subset of them), or check the to/from addresses2 (for things like Zulip):
All of my open source notifications that I need to address are labelled with Inbox/OSS. I never remove any of the GitHub or project labels added to emails above, I only ever remove Inbox/OSS once something has been dealt with.
I also create a saved search with the open source emails that I want to prioritise:
in:Inbox/* (in:GH/Author OR in:GH/Assigned OR in:"GH/Review Requested" OR in:"Rust/Compiler Team" OR in:Rust/Zulip)And that’s how I manage my notifications using email labels and rules. There are a couple changes that I wish GitHub and Fastmail would make:
If GitHub could add a merged value for X-GitHub-Reason then that would be great.
Fastmail’s mail rules checking for labels applied by previous rules would make it possible to encode some more complex logic in the mail rules without duplication.
Fastmail’s labels apply to specific emails, not conversation threads, which can make it difficult to do some searches - asking for all threads that aren’t, for example, labelled GH/Team Mention is difficult, because that search will still find those threads because of the emails within the thread without that label.
Thanks for reading!
Please don’t write GitHub comments deliberately to trick this rule, thanks :)
I use Fastmail’s masked emails so something like the Rust Zulip has a distinct to email address that I can match on.