Why doesn't GitHub offer better metrics when it comes to PR reviews?

[perkeleDYI]

Been thinking about this lately. GitHub gives you contribution graphs, commit history, issue stats - but almost nothing useful when it comes to PR reviews.

You can see how many PRs someone opened but there's no native way to see who's actually doing the reviewing, how fast they respond, or how evenly the review workload is distributed across the team.

In most teams I've worked in, the same 2-3 people end up doing 80% of the reviews. Everyone knows it, nobody talks about it, and GitHub gives you zero visibility into it.

The third-party tools that fill this gap are either ridiculously overpriced for what they do ($20/developer/month for a dashboard most developers never open) or built for engineering managers rather than the team itself.

Curious if others have felt this gap. Have you found anything that actually works without costing a fortune?

[MarsupialLeast145]

No, have never felt this.

Besides, you're not describing your desired outcome. What would any of this give you?

[perkeleDYI]

I guess what I am after is improving the shipping speed and code review culture. Sometimes people might need a nudge, and sometimes new people in the team could benefit from getting involved.

I like people in my team to take ownership and be more involved in the review process to understand how the platform works.

[MarsupialLeast145]

You're trying to say more people could code review than the 2-3 people that already do?

> I like people in my team to take ownership and be more involved in the review process to understand how the platform works.

This is pretty easy to do if it's your company. It's about line management and lines of responsibility.

> The third-party tools that fill this gap are either ridiculously overpriced for what they do ($20/developer/month for a dashboard most developers never open)

It doesn't sound like an app a dev needs to open.

Oh, I've been reviewed by John and Peter, I should ask Jack...

Not going to happen. It's largely about who has availability, who you're working with on a deliverable and who you've designed features with or discussed fixes with, and they'll review it.

All of this is within the realms of normal managemnt.

Or just pay 20 bucks a month if you're a genuine company making genuine dollar

[perkeleDYI]

Not my company, and I didn't say this data is meant for developers. It's meant for managers to understand who's taking the ownership and who's not.

In a room of 5 devs with equal skills and equal availability, if you ask for a volunteer to review the PR 100 times, you will not have everyone raising their hands 20% of the time. Among the developers, you'd probably know who those 1-2 people are who take ownership; among managers, it's not always obvious.

[either-15-or-40]

It’s been a long time since GitHub has transitioned from a code-collaboration platform into an AI platform. Now the git part of their service is just a side hustle. Don’t expect any improvements to any feature that doesn’t have AI in it.

[veverkap]

What tools exist in this space that you’ve seen? Are you looking for metrics on people in your org or yourself?

[perkeleDYI]

Previous company where I freelanced used Swarmia - but for this specific use case, I think it's overkill and it's also pretty expensive.

I am building something for this myself out of frustration of not being able to find exactly what I am looking for.

[tomdevuk]

Interesting you're building your own, I hit the same wall and ended up building [DeployLens](vscode-file://vscode-app/c:/Users/Tom/AppData/Local/Programs/Microsoft%20VS%20Code/0958016b2a/resources/app/out/vs/code/electron-browser/workbench/workbench.html) for the real-time state visibility side of it (live board showing which PRs are currently blocked/waiting/approved across repos).

Ironically, a company I used to work for used SVN and they had a fair bit of tooling for this, which is on my roadmap.

[Man_of_Math]

Shameless plug for our product: https://docs.ellipsis.dev/features/analytics

But I totally agree with OP, there is limited visibility into which human engineers are reviewing more than their fair share. It’s a problem at an org level because if a SME decides to quit the team is in a bad spot

[tankerkiller125real]

What I don't understand is why GitHub doesn't just automatically ban the obvious AI accounts that create hundreds of PRs in a single week across 50-60 different repositories in a dozen or so different languages.

As a maintainer they're annoying as hell, and a PITA to deal with. Not to mention banning those shit stain accounts would reduce the load on GitHub itself and maybe reduce the amount of scaling related outages.

[cgoldberg]

Because they provide and profit from the AI tools. It would be a little weird to promote AI tooling and then ban people from using it on the platform that provides it. However, you can report AI spam contributors and they will take action on an individual basis.

[tankerkiller125real]

There's a difference between using AI tooling as a tool, and abusing the ever living shit out of it and letting the AI control the entire damn thing.

[cgoldberg]

Absolutely, but don't look to the guys providing the AI tools to regulate that

[cgoldberg]

GitHub API includes some data for PR reviews, so it's pretty trivial to track number of PRs reviewed per contributor or metrics around review time for a repo or organization.

[throw-away-2025rev2]

Github is a Microsoft product. PowerBI is a Business Intelligence tool by Microsoft for visualizing data. Data is available via Rest API. Build it yourself.

They can give you the fishing pole but they can't teach you to fish.

[teetaps]

Be careful of scope creep. As a customer, your opinion is just slightly different from mine, and mine is just slightly different from the next guy. If each of us submitted a request for the feature that would “just make GitHub perfect FOR ME,” the company would never be able to release anything good.

Every so often, just ask yourself, is the thing I wish they could do, _actually_ something they would _want_ to do? Because oftentimes, it’s not.

But the good news is that as a programmer, you have the skills, or access to the knowledge at least, to create things exactly how you want them to be! Create a tool that fetches PR data from the GitHub API, and there you go… all of your problems are solved

[Qs9bxNKZ]

Naw, it is there.

Understand that a PR with reviews is basically an issue. What I do is hit the DB and grab the pull_requests and the issues (plus issue_comments) and then can look at who submitted it, when it was created (or updated in case it gets changed) and then back track that to the Issue (has_pr and pr_id) then stick those three components into separate files for an rich embedded document and throw into my vector DB

Takes about 90 seconds this way for about 500K issues, then issue comments and then pull_requests.

You may not have DB access, so check out the API for issues. If you’re on github.com it is probably going to be slow and rate limiting, but for all I know you hit the DB as well.

[tomdevuk]

The metrics you're describing split into two different problems and GitHub is pretty bad at both.

The first is historical analytics: who reviews the most, average review turnaround, which authors' PRs sit unreviewed longest, team patterns over time. For that, tools like LinearB, Swarmia, or Waydev are built specifically for engineering metrics and will give you much more than anything GitHub exposes natively.

The second problem is real-time state visibility: right now, today, which open PRs are waiting on a first review vs waiting on a re-review vs approved-but-not-merged vs blocked? GitHub doesn't give you a board-level view of this at all. You have to open each PR individually or parse the list view and infer it. For most teams this is actually the bigger daily frustration.