---
title: Pull Request Acceptance Analysis
url: https://www.emergentmind.com/topics/pull-request-acceptance
type: topic
---

# Pull Request Acceptance Analysis

Pull request (PR) acceptance is the process by which repository maintainers evaluate and decide whether to merge proposed changes submitted by contributors into the main codebase. This decision-making process is multi-faceted, integrating signals from code quality, contributor history, project norms, ecosystem-wide context, and, more recently, the characteristics of both human and AI-generated submissions. The surge in large language models (LLMs) and socio-technical integrations has further diversified both the determinants and predictability of PR acceptance.

## 1. Definitions and Core Quantitative Metrics

A pull request is considered “accepted” if it is merged into the repository’s main branch; it is “rejected” if closed without merge. The acceptance rate over a batch of PRs is typically formalized as

\[
P_\text{accept} = \frac{N_\text{merged}}{N_\text{total PRs}}
\]

where \( N_\text{merged} \) is the number of merged PRs and \( N_\text{total PRs} \) the total evaluated. Most studies further track ancillary metrics such as PR lifetime, number of commits, lines added/deleted, number of review comments, and project- or author-level reputation scores [1812.06269][2003.01153][2505.07700][2410.14695].

The acceptance decision encodes both technical judgments (is the patch suitable, correct, and in line with architecture?) and social judgments (does the contributor have a strong track record, is there community endorsement, does the change match evolving project norms?).

## 2. Predictive Factors and Model-Based Insights

State-of-the-art predictive models for PR acceptance leverage dozens of technical, social, and historical features. Random Forests and logistic regression are recurrently used to capture both linear and complex, nonlinear relationships [2003.01153][2007.04816][2410.14695].

Key determinant classes include:

- **PR-intrinsic variables**: size (additions/deletions), number of modified files, PR “age”, number of commits, presence of linked issue, and review-phase signals such as code review comments and discussion volume.
- **Contributor history**: author’s prior accepted PR ratio, ecosystem-wide contribution volume, intra-project and cross-project collaboration metrics, and social proximity to integrators.
- **Repository attributes**: historic acceptance “leniency”, project size/activity, and dependency graph positions.
- **Ecosystem features**: PRs and issues filed in external projects, participation in up/downstream repositories, and network centrality in the wider ecosystem graph [2410.14695][2007.04816].

Empirical models routinely achieve high predictive accuracy—AUC-ROC values of 0.94–0.95 using 14–17 minimal features are reported for NPM-scale corpora [2003.01153][2007.04816][2410.14695]. The most influential variables are PR age (negative correlation with acceptance), repository acceptance rate (highly positive), number of PRs/comments (complex, often U-shaped), contributor prior success, and closeness/centrality in collaboration networks.

## 3. Quantitative Effects of Technical and Social Signals

Technical code-quality signals wield less predictive power over PR acceptance than social and reputational factors. Large-scale studies using static analysis (PMD, Pylint, Semgrep) consistently find negligible or zero effect of code-smell counts, coding style violations, or even critical (P1–P4) design issues on acceptance probability; metrics such as cyclomatic complexity or code-clone rates are not reliable determinants [1908.09321][2601.21102]. Instead, code review suggestions and reviewer–submitter interactions can produce significant merge-rate uplifts (~10.5% absolute increase) but at the cost of longer review cycles and greater discussion volume [2502.04835]. Structured suggestions are particularly effective as onboarding tools for newcomers but do not meaningfully reduce code complexity metrics.

Social factors dominate: prior collaboration with reviewers, community standing, and integration into the project’s core contributor network strongly predict both acceptance and the velocity of future contributions [2410.14695][1812.06269][1902.04060]. Acceptance rates are also sensitive to project norms (labeling practices, issue referencing, explicit attention to documentation), as well as upstream/downstream dependency relations within the software ecosystem [2207.04933][2410.14695].

## 4. PR Acceptance in the Age of AI and Automation

The proliferation of AI-generated pull requests (via coding agents or LLM-based assistants) has introduced new axes of variance in PR acceptance [2505.07700][2602.08915][2601.21102][2509.14745]. Empirically, acceptance rates for AI-generated PRs depend on the agent, task type, and the presence or absence of explanatory context:

- **Acceptance rates for agent-generated PRs**: 
  - Agentic coding (Claude Code): 83.8% accepted, but only 54.9% merged without human revision, compared to a 91% acceptance for matched human PRs [2509.14745].
  - Silent AI PRs: Codex achieves ≈95.7% acceptance, but detailed static/delta code analysis (complexity, quality, vulnerability changes) fails to explain rejections—reviewers appear to respond to context and documentation rather than measured code deltas [2601.21102].
  - Cross-agent variance by task: Documentation PRs are accepted at much higher rates (e.g., Claude Code 92.3%) than feature or fix PRs (Codex 67.9%–83.0%; Devin 45.6% for fix), and task type is a more powerful predictor than agent [2602.08915].

  | Agent         | Overall Acceptance | Human Baseline | “As-Is” Merge Rate |
  |---------------|-------------------|---------------|--------------------|
  | Claude Code   | 83.8%             | 91.0%         | 54.9%              |
  | Codex (silent)| 95.7%             | —             | —                  |

Bot-generated PRs (e.g., Dependabot) are accepted at roughly half the rate of human submissions (37.38% vs. 72.53%) and experience significantly longer review latencies. The deficit is attributed to lack of social signaling, low perceived urgency, and high abandonment rates for large-scale, automated updates [2103.03591].

The task type exerts the largest effect: for instance, in AI-generated PRs, documentation and chore tasks can reach acceptance rates of 82–92%, while new features, bug fixes, and test-related PRs are 15–45 percentage points lower depending on the agent [2602.08915][2509.14745].

## 5. Human Judgment, Project Norms, and Ecosystem Context

Qualitative and mixed-methods analyses underscore the limitations of purely technical metrics for determining PR fate. Empirical themes driving PR rejection include scope misalignment, maintainability concerns, redundancy with active PRs, procedural/administrative barriers (e.g., missing CLA), and lack of contextual documentation [2505.07700][2601.21102][2509.14745]. Particularly in the absence of discussion (“silent PRs”), reviewers’ decisions hinge on unmeasured factors such as project policy familiarity and the perceived descriptiveness of PR messages.

Ecosystem-wide involvement augments acceptance odds: contributors who engage in upstream/downstream projects, maintain issue activity in related repositories, or possess high second-order centrality in collaboration networks enjoy 10–38% higher odds of PR acceptance, with “direct collaboration” being the single strongest predictor [2410.14695]. These ecosystemic effects partially offset the greater unpredictability of newcomer submissions—newcomers lack historic interaction data, reducing model precision.

Within the NPM ecosystem, external PRs (non-core maintainers) are accepted at rates comparable to internal ones (∼55.7% vs. 51.0%), and focusing on documented issue closures, explicit labeling, and documentation changes further boosts merge odds [2207.04933].

## 6. Impact of Process Automation and Continuous Integration

The introduction of automated workflows (e.g., GitHub Actions, CI/CD checks) fundamentally shifts PR acceptance dynamics. Empirical observations include:

- Increased rejection rates post-adoption, often with fewer human comments for rejected PRs and more communication in accepted PRs [2206.14118].
- Median time-to-merge for accepted PRs grows, consistent with additional automated gatekeeping and iterative feedback-imposed latency.
- Code quality Actions can mitigate rejection rates specifically, but not all Action categories improve throughput or acceptance percentages.
- PRs failing automated checks are more likely to be quickly closed, with less human explanation, adding to contributor friction.

Recommended best practices for maintainers include staged onboarding, explicit documentation of automated policies, reviewer assignment for automated PRs, and careful calibration of automation to avoid suppressing valuable community submissions.

## 7. Practical Implications, Recommendations, and Future Directions

Actionable strategies have emerged for both contributors and maintainers:

- **Contributors**: Increase likelihood of PR acceptance by keeping changes small and scoped (1–3 commits, ≤25 lines, ≤4 files), referencing related issues, aligning with coding standards, and proactively engaging with maintainers, especially for nontrivial or cross-project changes. For AI-generated submissions, provide context and rationale, address security and complexity metrics, and minimize code deltas [2601.21102][2505.07700][2509.14745][2207.04933].
- **Maintainers/Integrators**: Rank incoming PRs using reputation, collaboration, and activity-based measures; surface project acceptance trends; establish explicit review and automation policies; and offer feedback, especially for rejected or languishing PRs. For optimal community health, rapid, constructive, and transparent PR processing is critical—acceptance rates correlate strongly with contributor retention and subsequent engagement [1812.06269].
- **Research Directions**: Model interpretability (e.g., SHAP values), semantic and cross-project metrics, the role of AI-explainability in automated PRs, and deeper analysis of the intersection between social signals, ecosystem history, and technical change content remain open areas [2410.14695][2007.04816][2601.21102].

In total, pull request acceptance is a high-dimensional process at the interaction of software, social networks, and increasingly, artificial intelligence. Robust predictive models, deep qualitative analyses, and integrated process-aware tooling now offer nuanced guidance to project stakeholders seeking to maximize PR throughput, software quality, and contributor sustainability.

Source: https://www.emergentmind.com/topics/pull-request-acceptance