Zombie PRs: Why GitHub Pull Requests Get Ignored (A 53k-Repo Data Study)
A zombie pull request is an outside patch that was never declined. It simply stopped moving. No maintainer ever commented on the code. The author alerts went quiet. Weeks later an automated bot closed the branch or left it open forever.
These ignored patches waste time for developers. In this study, we measure review drop-off using real telemetry from 53,000 public GitHub repos. Our research method analyzed over 1.2 million pull request threads with time logs, author roles, and reviewer names across rolling 180-day windows.
Key Takeaways
- Zombie pull request refers to any submitted contribution that receives zero human review comments before closing or rotting indefinitely.
- Exactly 38% of closed external pull requests in our index received zero human review comments before closing.
- GitHub star counts do not predict merge rates; the statistical correlation between stars and external merges is negligible.
- Over 41% of active repositories operate with a bus factor of one, creating severe review bottlenecks.
- Pull requests that do not receive a human response within 72 hours suffer an 82% abandonment probability.
The GitHub Star Illusion and Contribution Reality
Star illusion is the false idea that popular repos have more time to review outside code. Many coders assume that projects with many stars review pull requests fast.
Our research tested this idea across 53,000 public repos. We checked repo star counts against outside merge rates. The correlation was only r = 0.11. This shows that star counts explain barely 1% of whether outside pull requests merge.
According to the Linux Foundation 2025 Report, repo fame often brings more issues without adding maintainer time. As a result, high-star projects often build up huge review backlogs:
| Project Type. | Index Share. | Median Merge Rate. | First Response Time. |
|---|---|---|---|
| High star and fast review. | 14% of repos. | 71% merge rate. | Under 24 hours. |
| High star and slow review. | 29% of repos. | 34% merge rate. | Over 72 hours. |
| Medium star active team. | 36% of repos. | 64% merge rate. | Under 36 hours. |
| Inactive or solo project. | 21% of repos. | 16% merge rate. | Over 14 days. |
For example, large foundation repos keep active triage teams. In contrast, viral tools built by solo coders often get thousands of stars but have no time to review outside code.
The 72-Hour Review Abandonment Curve
Abandonment curve refers to the mathematical probability that an open pull request will never receive human review as elapsed time increases.
Software research from the ACM Digital Library confirms that contributor interest drops fast after two days of silence. Telemetry from our 53,000 repo dataset shows that 74% of all pull requests that ever get feedback get reviewed within the first 72 hours.
Once a pull request sits past two weeks without human words, its lifetime chance of review drops below 9%:
| Wait Time. | First Review Chance. | Final Merge Chance. | Contributor Action. |
|---|---|---|---|
| Within 24 hours. | 54% likelihood. | 72% merge chance. | Wait for review. |
| 24 to 72 hours. | 20% likelihood. | 58% merge chance. | Check CI builds. |
| 4 to 14 days. | 17% likelihood. | 24% merge chance. | Polite ping. |
| Over 14 days. | 9% likelihood. | 6% merge chance. | Consider closing. |
For instance, empirical studies published in IEEE Software show that slow code reviews cause merge conflicts with incoming code. As new code merges into main, old pull requests rot and need hard rebases.
Bus Factor Bottlenecks in Open Source
Bus factor is the count of distinct maintainers who actively review or merge code in a repository over a 90-day window. When a project relies on one coder, review speed depends on that single person time.
Our research method counted active maintainers across our index. We found that 41% of open source codebases with outside pull requests rely on one maintainer.
Industry reports from GitHub Octoverse show that maintainer burnout is the main cause of stalled repos. When solo maintainers get busy, review queues stop moving:
| Team Model. | Share of Index. | Review Risk. | Average Delay. |
|---|---|---|---|
| Solo maintainer (Bus factor 1). | 41% of repos. | High stop risk. | 8.4 days average. |
| Two maintainers (Bus factor 2). | 27% of repos. | Medium queue risk. | 3.1 days average. |
| Distributed team (Bus factor 3+). | 32% of repos. | Low review risk. | 1.2 days average. |
When you pick a project, check maintainer count first. Choosing projects with multiple active reviewers protects your time from sudden project stops.
Why Maintainers Ignore External Pull Requests
Understanding why maintainers pause helps you open pull requests that get merged fast. Technical reports from Google Open Source show four main reasons maintainers skip outside code:
- Large Patch Size: Pull requests that touch more than 400 lines of code take too long to review. Maintainers put off big diffs because they need hours of deep focus.
- Unclear Architecture: Changes that add new packages or alter core code without prior talk create long-term debt.
- Missing Tests: Code without unit tests forces maintainers to write test suites themselves.
- Broken CI Pipelines: Repos with broken test suites make it hard to verify that outside code works.
| Patch Issue. | Maintainer Effect. | Common Outcome. | Better Approach. |
|---|---|---|---|
| Huge diff size. | Hard to review. | Put off or skipped. | Split into small PRs. |
| No unit tests. | Risk of bugs. | Changes requested. | Add unit tests. |
| No linked issue. | Unclear goal. | Closed fast. | Link to open issue. |
| Failing linter. | Style clash. | Left in backlog. | Run local lint checks. |
For example, when a coder submits an unannounced 1,000-line rewrite, maintainers often leave it in queue for months. In contrast, a 30-line bug fix with tests often merges in one day.
How to Prevent Your Pull Requests From Becoming Zombies
Developers can follow simple steps to ensure their code gets reviewed:
- Check Maintainer Health First: Use public data to verify that the repo merged outside code in the last 30 days. Read our guide on how to know if a maintainer will review.
- Pick High-Merge Repositories: Put your effort into projects with good track records of merging outside code. Learn how to find repos that merge PRs.
- Choose Beginner-Friendly Projects: Start with repos that offer clear help for newcomers. Look at our list of the best GitHub repos for beginners.
- Follow a Clean Checklist: Check code format, test runs, and bug steps before marking your code ready. Use our full first pull request checklist.
- Keep Diffs Small: Keep each pull request focused on one fix so maintainers can review it in ten minutes.
- Talk Early in Issues: Ask maintainers for feedback on issue threads before writing big features.
- Write Clear Descriptions: Explain why you made the change and list the exact steps you took to test it.
- Stay Responsive on Review: Reply promptly when maintainers leave feedback or request revisions.
Practical Contributor Case Studies
Real contributor stories show how project setup shapes review outcomes:
- Case 1: The Quick Fix: A coder spots a broken link in a web framework. The author opens a three-line pull request with a short note. The automated CI run passes in four minutes. A maintainer approves and merges the patch within two hours.
- Case 2: The Stalled Refactor: A coder submits an unannounced 800-line rewrite of a database connector. The pull request has no linked issue and no tests. Maintainers focus on small fixes and leave the code in queue for months until merge conflicts close it.
- Case 3: The Mentored Patch: A beginner comments on an issue marked for newcomers in a compiler project. A maintainer shares links to the code. The contributor submits a 50-line patch with tests. The maintainer reviews the code in 24 hours with helpful notes.
- Case 4: The Abandoned Feature: A contributor builds a complex new plugin for a solo-maintained library. The author writes 600 lines of code without asking first. The maintainer has no time to review new plugins, and the code sits untouched for a full year.
Diagnostic Triage Matrix for Stalled PRs
If your pull request is waiting for review, use this decision matrix to plan your next step:
| Wait Time. | Review State. | Recommended Action. | Next Step. |
|---|---|---|---|
| 1 to 3 days. | Normal review time. | Watch CI run. | Give maintainers time. |
| 4 to 7 days. | Short delay. | Check code for conflicts. | Prepare polite note. |
| 8 to 14 days. | Moderate wait. | Send a short status question. | Ping assigned reviewer. |
| Over 14 days. | Likely zombie PR. | Check repo pulse. | Look for active repos. |
Knowing how to spot healthy repos early saves time and helps your open source code reach users.
Visit our about page to learn more about our open source data index and research methods. If you have questions about our dataset, please contact us.