Pull requests are a sign of a healthy GitHub repo. It’s an even better sign when your community contributes those PRs.
GitHub PRs from your developer community aren’t just about adding features or fixing bugs—they signal that your DevRel program is paying off. It’s one thing to invite users to contribute to your open-source software; it’s another for them to take you up on it.
To encourage and reinforce this behavior, it’s helpful to know it’s happening immediately, follow up, and lend a helping hand with haste.
This playbook will show you how to tag meaningful source-specific activity (like when a PR is submitted on GitHub). Even better, we’ll also walk through how to notify your team members on Slack when a PR is submitted.
What you’ll need
Our first step is to connect your repo to Common Room so we can pull in activity and create filters for our alerts. To do that, head to the Settings menu in Common Room and select Connect GitHub.
After clicking to connect, you’ll be asked to authenticate your GitHub identity and select any repos where admin approval is granted.
And once authenticated is verified, you’ll see activity data from GitHub in your Common Room instance after a few minutes.
With your GitHub repos connected, we can head to the 💬 Activity pane in Common Room to get a sense of volume, activity type, etc.
Because Common Room is a single platform for operationalizing activity across many digital channels, many “rooms” (what we call a customer instance) have multiple sources connected.
For our Uncommon community, we have more than 186k activities tracked! That’s way too many for this use case, so we’ll want to add filters to extract developer signals from the noise on channels like LinkedIn or Twitter.
From this view, we can click on + Add filter and select Source activity type from the menu. This will allow us to pinpoint GitHub pull requests.
With the source filter selected, we can hover over GitHub and check the button for Pull requests submitted. This brings our activity down to a couple thousand. Better, but still too much volume for our use case.
To filter further, we can click on the calendar icon on the right side of the activity panel and choose Last 7 days. This narrows our results to a couple dozen pull requests from the last seven days. Much more manageable.
Now, let's create an alert to send real-time notifications to Slack.
Head over to the team alerts menu on the left nav and click the + Create team alert.
This will take us to the alert workflow, where we can set up a trigger from an event (PR submitted, in this case), a filter to narrow alerts if needed, and an action to send the alert to a destination.
First, we’ll select a trigger to initiate our alert. We’ll select Community Wide from the trigger dropdown and select 💬 New activity as our event.
We’re then taken to a filter step. And from here, we can select Activity filters and add the same criteria we used above: source activity type = GitHub and activity = pull requests submitted.
We also don’t want alerts when our own team members submit pull requests, so we’ll add an additional member filter to exclude our team.
And for our final step in our team alert workflow, we’ll select to send alerts to Slack and choose the channel we want alerts to go to.
When you click "Create alert," you’ll see a confirmation modal to send a test message. We want to test what this looks like, so we’ll send it.
Everything looks good and our channel was updated, so we’ll click "Create and turn on." And with that, our alert is live!
With this playbook, we isolated meaningful activity from GitHub and alerted our team to take action. However, this is just scratching the surface of what’s possible by combining activity tracking, filters, tagging, and automated workflows in Common Room.
You could continue down this path and run the same play for GitHub issues, comments, and more. And that’s just for the GitHub source. The same process can easily be applied to other sources, such as LinkedIn, Stack Overflow, Twitter, and any of our dozens of integrations.