Let's share the experience of watching repositories, doing review and reacting to the messages.

I am going to review some common tips of organising pull-request watching with Google Mail, that work for me.

Why not Slack

Slack is integrated merely with GitHub but has no grouping, no priorities. Messages go in a timeline feed, so comments of different pull-requests alternate and intermix.

Google Mail benefits

Google Mail is very smart and helpful in organising email processing and have many features to be productive. We are going review some of them.

Messages chains

Google Mail groups all the incoming messages into the chains and puts all the GitHub’s comments of one pull-request in one. No matter how many unread messages of one pull-request you have - they all appear as one unread chain (with the number of incomes).

❗ Chaining breaks after renaming pull-request, and all the new comments with getting in the new group. That is why do not recommend to name pull-request correctly for the first time.

Labels

Labels allow organising all the emails in groups. They work like folders, but you can add multiple labels to a message. We will use them to specify the message types, e.g. “For review”, “My team”, “OSS” and so on.

❗ Labels are flexible, and you could reconfigure them at any time when you will need to reorganise your flow.

Filters

Google Mail uses customisable rules to preprocess incoming messages. This is the excellent way to classify emails and apply the source-specific label to them.

Prioritisation

Simple "prioritisation" could be maid manual by arranging labels decreasing the urgency of the messages you have to react.

Snoozing

Snoozing is the new feature. It is handy in the context of pull-requests watching because it allows postponing the incoming mail immediately when you are not able to react at the moment.

Now we are going to tune up those features to improve the organisation of watching and reviewing pull-requests process.

Google Mail features in action

1. Labels

First of all, we have to think about repositories you are watching and the urgency of incoming data. Here is my sample. You could use it to start and make it more proper to your case:

Review - holds the pull-requests from where someone is asking my review with the GitHub's "Reviewers" tool.

Backend - is used to put messages from the backend team. Here might be some pull-requests which are in work now (WIP) and probably no review has been requested yet. As I am in the back-end team, it is essential to keep track of events of my team.

Frontend labels used to mark frontend team's pull-requests. It is less important to watch those pull-requests but lets me observe what is happening in the frontend part of Amplifr.

Team: here are all the pull-request of the all Amplifr working project repositories. Most of the are auxiliary and don't change too often.

Used gems. At the backend projects, written with Ruby on Rails, we use many Ruby gems. And it is handy to follow all the updates, that is why I watch some repositories like twitter gem.
But this updates are not urgent and could be viewed at the free time.

OSS - this label is for following pull-requests of the open source projects I contribute to or like to track updates.

GITHUB - I use this label to mark all the messages from GitHub to overview the total count.

Filters

These filters work for me:

Matches: from:(notifications@github.com)
Do this: Apply label "GITHUB", Never send it to Spam

Matches: from:(noreply@github.com) subject:(Github Subscribed)
Do this: Mark as read, Delete it

Matches: from:(notifications@github.com) to:(review_requested@noreply.github.com)
Do this: Apply label "1) Review", Mark it as important

Matches: to:(evilmartians/amplifr <amplifr@noreply.github.com>)
Do this: Apply label "2) Backend", Mark it as important

Matches: to:(evilmartians/amplifr-front <amplifr@noreply.github.com>)
Do this: Apply label "3) Frontend"

Matches: (to:(gazay/gon) OR to:(sferik/twitter) OR to:(philnash/bitly) OR :to:(wilddima/logux_rails)
Do this: Apply label "5) Used gems"

❗ You could download the base filters from my Gist, import them into Google Mail, and start tuning them for your flow.

After that, we can see all the messages grouped by the urgency of them. A quick view of the label's table let you see how many tasks are pending.

Google Mail Checker

"GMail Checker" is the excellent browser plugin for checking the mail and for getting notified about new messages.

The main features, I use, are:

1) "Do not disturb" for the full-screen mode.

This option is beneficial not to lose concentration when you are coding in the VIM or browsing something in full screen.

2) Notify for the specified labels email:

This feature lets me react fast for the most crucial messages.

The mail checker also has many features, which would be very useful to improve usage of the mail.

Mental setup

When automation works well, you only need to view comments starting from to most urgent and react to them. And here is the most critical part for human factor come out.

Imaging the cause, you open the new email, read the comments, go to the GitHub, and then you look aside and switch to other activity, forgetting about this message. In this case, you miss the sight because you have the letter read in Google Mail but without no reaction.

❗The primary mental setup - is to review incoming mail intently and always make a reaction:

• directly, with approving pull-request, doing the review or commenting
• implicitly, with snoozing the message (for the more suitable time)
• or with marking the email "unread" to leave it for the next session, you will work on the email.

Wrap up

Spending one hour for organising incoming emails let to save more time in the future, It:

• makes email browsing smarter by using prioritisation and labels
• shorten the reaction time for the most urgent messages
• gives the flexibility - all the settings could be changed at any time for any situation to perform maximum

Thanks for reading.