Available for hire

The Only Four GitHub PR Filters You Need

Managing pull requests (PRs) efficiently is key to keeping your development pipeline flowing. When PRs pile up, it slows down productivity, leads to unnecessary context switching, and can create a backlog that makes it hard to identify the most important tasks.

The primary goal of these filters is to reduce Work In Progress (WIP) time, minimizing the period between when work is initiated and when it’s merged and delivered. By focusing on PRs that are ready for review or merge, you ensure that tasks move through the pipeline quickly, preventing them from lingering for days or weeks. This reduces the cognitive load on your team, allowing them to concentrate on current priorities rather than juggling outdated tasks. By cutting down WIP time, your team can focus more effectively on what’s important now, avoiding the distraction of wrapping up past work.

With these four essential GitHub PR filters, you’ll always know where to focus, ensuring that your team is working on the right things at the right time.

Actionable item filters

The “actionable” filters are designed to surface PRs that require immediate attention to keep the workflow moving efficiently. By prioritizing these filters, you ensure that the team stays focused on tasks that are important to the customer, reducing delays and keeping the codebase moving forward. Actionable filters help drive decisions during standups and daily reviews by highlighting the most pressing tasks, whether it’s merging an approved PR or assigning someone to review unreviewed work.

Approved and awaiting merge

Filter: is:pr is:open sort:updated-desc draft:false review:approved

These PRs are already reviewed and approved, meaning they are ready to merge. This list is where you should focus when closing out work and ensuring that the code is making its way into the main branch. Merging approved PRs as soon as possible reduces the chance of conflicts and keeps momentum going.

Why it matters:

  • Unmerged approved PRs are the low-hanging fruit of the development process: the work is done and just needs to be delivered. So deliver it!
  • They may also be blocking other work from happening.
  • These should be merged immediately unless there’s a good reason to delay.

Ready and awaiting review

Filter: is:pr is:open sort:created-asc draft:false review:none

This filter shows PRs that are open and ready for review but haven’t been reviewed yet. These PRs should get immediate attention from reviewers. The quicker you can move these through the review process, the faster they can be approved, merged, and moved off the board.

Why it matters:

  • These PRs represent the most immediate need for action from your reviewers.
  • By tackling these, you minimize review delays, keeping the team moving forward.
  • By tackling this list in order of PR creation, you’re reviewing the oldest work first.

Reference filters

Reference filters are meant to track PRs that don’t need immediate attention but are still important to monitor. This includes PRs that have already been reviewed but need changes before they can progress, as well as draft PRs that are still works in progress. These filters give you visibility into the overall workload without demanding immediate action. While they might not be the focus of daily standups, they provide context on what the team is working on and allow for future planning and resource allocation.

Needs changes

Filter: is:pr is:open sort:updated-desc draft:false review:changes_requested

These PRs have been reviewed, but changes were requested. While they don’t need immediate review, it’s important to monitor them to ensure that the author follows up and makes the necessary changes. You might consider automating the process of moving these PRs back into draft mode until the requested updates are made (more on that later).

Why it matters:

  • These PRs are often overlooked, leading to delays in implementing requested changes.
  • Converting them back to drafts signals that they are in progress, preventing confusion with PRs that are review-ready.

Drafts/WIP

Filter: is:pr is:open sort:updated-desc draft:true

Draft PRs represent work that is still in progress. While these don’t need immediate action, they give product managers and team leads visibility into what’s being worked on. Monitoring these helps ensure that in-progress work aligns with team priorities.

Why it matters:

  • These PRs indicate the team’s current focus areas and effort allocation.
  • Keeping an eye on drafts can help PMs and team leads better understand work distribution and team progress.

Customize to your needs

If you work in a monorepo or have specific labels that indicate team ownership, you can customize these filters further by adding additional criteria on top. For example:

is:pr is:open sort:updated-desc draft:false review:none label:backend

See results from multiple GitHub repos

These filters can also be used on GitHub’s global PR search page, giving you a merged PR queue across multiple projects. By adding the repo:yourorg/yourproject filter, you can limit your search to a specific repository, or include multiple repositories by chaining additional repo filters like repo:yourorg/yourproject repo:yourorg/anotherproject. This is especially useful if your team works across multiple codebases, allowing you to track PRs from different projects in a single, unified view. With this setup, you can manage and prioritize PRs across your entire organization, ensuring nothing slips through the cracks.

Use these filters for standups

These filters aren’t just for everyday management; they’re also perfect for standups. By quickly reviewing the “actionable” filters, you can provide real-time updates on when things will be merged and assign reviewers to unreviewed PRs. The “reference” filters (like “Needs Changes”) can be reviewed asynchronously.

Using these filters for standups also helps avoid the common managerial anti-pattern of checking in on every single open issue in the sprint. By focusing on PRs that are actionable or in progress, leads and PMs can see exactly what’s being worked on without diving into every open task. This streamlines standups, as the most important work is front and center, and if there isn’t a PR for a particular issue, it’s likely that the work hasn’t started yet. This approach fosters a more efficient meeting, allowing the team to focus on priorities rather than rehashing older, untouched tasks.

Automate it!

Wouldn’t it be great if PRs that needed changes automatically converted back to draft mode? You can easily set up a GitHub Action to do this for you. Here’s an example of how you could implement it:

name: Auto Convert Needs Changes to Draft
on:
  pull_request_review:
    types: [submitted]
jobs:
  convert_to_draft:
    if: github.event.review.state == 'changes_requested'
    runs-on: ubuntu-latest
    steps:
    - name: Convert PR to Draft
      run: gh pr ready --undo ${{ github.event.pull_request.number }}

With this automation, you’ll ensure that PRs requiring updates are visibly marked as draft, keeping the PR review process clear and organized.

Wrap up

Using these filters for standups not only keeps the team focused on current priorities but also prevents the inefficiency of checking in on every single open issue. Leads and PMs can quickly assess what’s in progress and what needs action, without micromanaging or revisiting tasks that haven’t moved forward. This allows them to infer that if there isn’t a PR for a particular issue, the work likely hasn’t started yet. By focusing on what’s actionable, the team can maintain momentum and avoid getting bogged down by unnecessary updates, leading to more productive standups and better overall workflow management.

Got any other essential filters you swear by? Email me about them (email link can be found on my About Me page).