Staying on top of a lot of projects on GitHub is frustrating. I've had my inbox blow up with low-information notifications, sifted through endless issues and PRs, and felt dumb after discovering something happened days ago that I needed to know or weigh in on.

One of the issues is context. As a senior developer or manager, you acquire hundreds of contexts you're operating under, each needing a different level of involvement and understanding.

We do not and should not give each context equal attention. You might be entirely in charge of the design and implementation of one system and advising on another once every few weeks. You might be deeply involved in the inner workings and politics of one GitHub repo and just want release notices from another. Or you maintain a library, and you want to know when issues and PRs on other repos mention your library without following their entire stream.

But we can only provide a few signals to GitHub: subscribe, watch, etc. On or off. It's improved recently; you can at least selectively watch all issues vs. PRs vs. security notices. But there is no priority attached, and there are no organizational tools to indicate that something is important for one context only.

What happens when a project is deprioritized, and you don't need to track a set of open source dependencies and issues? Or when you put down learning that new language for a few months?

What happens if you're responsible for a subsystem in a large repo? You end up subscribing to "all activity" in a repo (which doesn't even give you the full stream of events) and getting way too many notifications. You do need to know what's happening in the project, but the full stream is too much.

You could live with it and wade through everything every day. You could constantly rework what you're subscribed to. Maybe you could sign up with different email addresses and have different tracking personas 😬.

Or you could subscribe and scan in a better way. A way that lets you stay in the context you want to be in and filters out the noise. A way that gives you the option to dip into the broader event stream if needed but keeps it at bay if not.

This is what I wanted, so I created Yupdates. Integrating with GitHub was one of the original ideas. There are similar patterns across GitHub, RSS, Twitter, email, and bookmarks. The primary way we interface with these is "all or nothing" without any notion of the context we're in or how important we think certain topics are.

With the GitHub integration, Yupdates can track every issue and PR event. The events are fine-grained: every comment, every new push to a PR, every time a label is added or removed, etc.

To start, you can create a feed that tracks that full event stream, and that might be all you want. Just having this in a fast, scannable interface is helpful. But that can be something you look at occasionally. On regular days, you can look at focused feeds:

• Track the major lifecycle events for all issues. Get an event when they're opened and closed, but that's it. This allows you to selectively subscribe to ones that matter to you (there's often no simple filter or algorithm for that selection).
• Track all issues, but only include events that mention your subsystem. This is helpful for overactive repos or maintaining a library used across fifty others.
• Get an event every time a PR review is requested, even if you are not explicitly tagged. This is great if you want to help but you want to pick and choose. It's also great for developers and managers who want to stay tapped into the flow of the entire team.
• Get a notice when any PRs reference particular issues. You're waiting for a blocking issue to be fixed and want to track anything to do with it.
• Track every issue where a particular label is added. Yes, you can go to the GitHub interface and browse issues with a label, but it's better to get a distinct event when it happens and it gets very powerful in combination with filters and regex. Same for label removal when that is important.

This is just a sample of the types of feeds you can create. On top of this, feeds can be organized into groups which makes it easy tease out separate contexts. You can create groups for each context at work and groups for each thing you're interested in outside of work. Feeds can be in multiple groups. And feeds and groups can change quickly as things change. You can ignore entire groups for months. Yupdates will continue to monitor them, but you can ignore them and easily toggle updates/emails.

Here are snapshots of the event type filters for issues and PRs. You can focus on any combincation of these on top of any keyword or regex filters you need. And you can have different configurations across many feeds based on the same repo, each giving you a different view.

Event types for GitHub issues:

Event types for GitHub PRs:

There's more detail in the GitHub section of the FAQ.