Developer | PR Decline Rate

Definition (Hover Text)

Pull Request (PR) Decline Rate is the percentage of opened pull requests that are declined or rejected within a given period.

Source Tools

Github, Gitlab, Bitbucket, Azure Repo

Graph type

Line

X Axis - Days/Weeks/Months
Y Axis - Percentage

Filters

Branches & Developers

Hover Format on KPI

<From Date - To Date>: <PR Decline Rate %>

Fields on Explore

• Project

• Repository

• Branch

• Developer

• Days/Weeks

• Declined PRs

• Closed PRs

• PR Decline Rate

Business Logic

Calculation Formula

For a given time period (TStart, TEnd):

PR Decline Rate (%) = (DeclinedPR / ClosedPR) × 100

Where:

• TotalPR = OpenPR + DeclinedPR + MergedPR + SupersededPR

• ClosedPR = DeclinedPR + MergedPR

Definitions:

• DeclinedPR = Number of pull requests with a create date within the timeframe (TStart to TEnd) and status DECLINED.

• MergedPR = Number of pull requests with a create date within the timeframe (TStart to TEnd) and status MERGED.

• OpenPR = Number of pull requests with a create date within the timeframe (TStart to TEnd) and status OPEN.

Trend

A decreasing PR Decline Rate is a positive trend.

Maturity Levels

M1: > 80%
M2: 50 - 80%
M3: 20 - 50%
M4: 5-20%  
M5: <5%

Instance level thresholds

50

Configurations

Processor Fields

Nil

KPI Specific fields

Target KPI Value

How to Validate KPI

Suggested ways of working

• Accurately track the status of all pull requests, including those that are declined, with proper timestamps.

• Ensure declined pull requests are clearly tagged or labeled to differentiate them from merged or open PRs.

• Standardize the workflow for declining PRs to ensure consistency in how declines are logged and tracked.

Sample JQLs

N/A

Benefits of KPI

How does the KPI help

The PR Decline Rate KPI helps by identifying areas where pull requests are not meeting the required standards. It provides insight into common issues such as misalignment with project requirements, poor code quality, or communication gaps between developers and reviewers. By monitoring this KPI, teams can focus on improving code quality, clarifying requirements, and refining the review process, ultimately reducing wasted effort and improving overall efficiency.