Does this account for projects that merge commits outside of the GitHub interface?<p>NodeJS use a bot that manually merges the commits but closes the PRs: <a href="https://github.com/nodejs/node/pull/36661" rel="nofollow">https://github.com/nodejs/node/pull/36661</a>
My projects get a very discouraging rate of ~60%. That is probably because I reject a lot of PRs created by bots (dependabot, security fixes if they are only to dev dependencies).<p>Maybe because I merge commits manually.<p>I remember rejecting only a few PRs.<p>It seems very discouraging for new contributors.
Cool project! I've long wanted something like that but it's hard to find the right metrics.<p>When I'm contributing to a project, the thing I care most about is response time. If I submit a PR and the maintainer accepts it a year later, that's not very inviting. But if the maintainer gets back to me in a day and explains why they're rejecting my PR, that's actually a much better outcome.<p>I tried plugging in my own project (mtlynch/tinypilot), and I score a disappointing 60%. But I think what happens is that external contributors often aren't very familiar with git, so they'll try to fix merge conflicts by merging instead of rebasing, leading to PRs that are 10x larger due to merge noise.<p>In those cases, I cherry pick their commits into a new PR, but I'm guessing that counts as a rejected PR, even though their commits are getting merged in.
Author here! This is a small web app written in Python Flask and deployed on Cloud Run. It extracts data from GitHub via their GraphQL API and caches it in Firestore (just because it is way cheaper for a low traffic side project than running Redis).
Looks cool!<p>One feature recommendation: you might want to consider supporting people submitting the entire URL.
Currently, when you do that, you hit a 500.