Why GitHub notifications make it hard to get things done & how to fix it.
Making your notifications smarter, powerful, and meaningful.
If you’re anything like me, GitHub plays a pretty big role in the day-to-day work life. It’s where I host most of my code —both personal and professional —and where I collaborate with my team and peers on a variety of different projects.
An awesome benefit from having all of your work in a centralized area is that you can get every update for the different projects you’re working on all in one spot. The downside is that GitHub’s updates in particular kind of suck —which is annoying because they have so much potential to be good.
I crunched the numbers (math minor™ btw) and out of the hundreds to thousands of notifications I get each month, I only really cared about 15% of them. Which, again, kind of sucks.
Trying to use “The Platform” and why it doesn’t work
While there are a few popular ways to manage GitHub notifications, all of them feel incomplete. When I get a notification, there are three things that I want to know:
- Why am I getting this — When I get a notification, I want to know what it’s for. Did someone comment on an issue? Was I assigned something?
- Do I care about this — I don’t want notifications for issues and pull requests that I’m not directly participating on. If I’m not involved, I probably have more important things to focus on.
- How urgent is this — When confronted with more than one notification, I want to know which one I should click on first.
So with this in mind, let’s explore the different ways people try to solve these problems today.
Using the participating tab
Within GitHub’s notifications tab, there’s a sub-tab titled “participating” — this is where you’ll find all the notifications that GitHub thinks is relevant to you.
This is pretty great, and also happens to be how I used to manage my notifications for the past year or so — but even then, this isn’t nearly good enough.
While this checks off the second item on my list, it doesn’t address the other two. Sure, I can see all the notifications that I care about, but I still don’t know why I care any of them, nor do I know how important each of them are to me.
Imagine if I had two notifications: one for a coworker commenting on an issue I opened, and another for somebody @mention’ing me for the 17th time on a pull request that’s assigned to me, has been open for two weeks, and requests my review (extreme example, but you get the point).
Without the notification telling me why I’m getting it, there’s no way for me to know these things without having to open each and every one and investigating myself. When there are only two notifications, that’s probably not a big deal, but what if I had ten? Twenty? 62 million? While this isn’t always a problem, this isn’t something I want to have to worry about; I want my most important notifications front and center.
The problems here might be acceptable to ignore on a small scale, but start throwing in a bit more activity and this approach quickly falls apart.
Using email (ugh)
Email is a pain to work with as it is, so right out the gate I don’t like this approach — but let’s give it a shot.
So with email, you have the ability to filter things, which is nice. This means with enough effort, you can set up a motley crew of different filters to remove any notifications which aren’t relevant to you.
Another added benefit to emails is that they can provide you with some context on what the notification is — like what somebody commented or if a pull request was merged, which is super cool and helpful.
I like this, it even checks off the first item on my list, but it feels really clunky and requires a lot of set up. It also doesn’t really say how important each notification is. While this approach definitely has value, it’s not enough for what I want.
Using third party apps
So, if this is such a big problem, then surely somebody must have invented a solution already, right? I’ll even take an overzealous NPM package at this point.
Luckily, it turns out there kind of is a solution out there — there’s this pretty cool web-app called Octobox which aims to turn your GitHub notifications into something like Gmail.
This is really interesting and a great tool and ends up checking off the first two items on my list (after you set up enough filters), but it doesn’t address the third.
Octobox is great at organizing all your notifications with filters (like email) and briefly telling you what the notification is for, but it doesn’t tell you how important it is. It makes sense when you think about it — this app isn’t really opinionated, which is totally fine, but just not what I want.
Plus, you need to set up a lot of integrations in each repository you want to track notifications for, which is especially a pain when you’re involved in some private organizations.
Also it costs money for private repositories, and who likes to spend money?
So Octobox turns out to be a pretty solid solution, but still doesn’t do everything that I want.
Nothing works, so let’s make our own thing — Arriving on Meteorite
At this point, I’m getting impatient and starting to lose hope that something actually exists out there.
So to recap, when I get a GitHub notification, I want to know these three things:
- Why am I getting this — When I get a notification, I want to know what it’s for. Did someone comment on an issue? Was I assigned something?
- Do I care about this — I don’t want notifications for issues and pull requests that I’m not directly participating on. If I’m not involved, I probably have more important things to focus on.
- How urgent is this — When confronted with more than one notification, I want to know which one I should click on first.
So after checking out all of the alternatives, I decided to just make the dream web-app that checks off everything on the list myself: introducing Meteorite — Smarter GitHub notifications.
I figured it should be straightforward enough — have a strategy for fetching and syncing notifications in real-time, filter out the non-important ones (keep things like where you’re assigned, mentioned, review requested, etc.), keep track of the notification thread history, and compute an importance score based on its activity.
Meteorite is just an alternative to managing your GitHub notifications. It’s geared towards helping surface all of the notifications that are relevant and most important to you.
In a nutshell, the primary things it’ll do for you are:
- Sort and score your notifications based on their importance, so we can surface the most critical updates to the top of your queue.
- Provide you with quick context for why you’re receiving each notification.
- Allow you to opt in for desktop notifications whenever you receive important updates to help notify you right away.
- Helps call out pull requests or issues that require your attention, like old PRs that require your review or really active threads.
- Protect you from useless spammy notifications that you don’t care about.
- Let you focus in on specific types of notifications that matter to you, like when your review is requested for a pull request or you were assigned an issue.
- Shows you statistics that help you understand how you interact with notifications on a daily basis.
This project is also totally decentralized — any and all heuristic information used to score and rank your notifications is stored locally on your own computer. No databases, no nonsense.
Well, does it actually work?
Everybody works a little differently, but for me at least, this project have been a life saver. I’ve been using Meteorite for the past few months at my job and have been absolutely loving it. It makes it so much easier to track my work and reviews across a variety of different projects and keep me organized.
This project is completely free and open sourced on GitHub with no installing of any kind of apps required. Feel free to check it out, submit requests, and/or contribute if that’s your jam.
This project has been super helpful for me and I hope others might find it useful too!
