Dataset: Issues & Pull Requests
Entity: Pull Requests, Issues
Field ID: review_rejected_at
Type: Datetime
Description: The datetime at which a pull request was first rejected after a review (CHANGES_REQUESTED). For issues, it is the timestamp of the oldest rejection review across all resolving pull requests.
Source: Calculated from pull request reviews
Transformation logic:
Pull requests: It is the submission datetime of the first pull request review with the status “request changes”.
Issues: It is the submission datetime of the oldest “request changes'' review across all resolving pull requests. Resolving pull requests are pull requests that reference the issue via auto-closing keywords.
From: |
|
Github (PRs, Issues) | Calculated |
Gitlab (PRs, Issues) | Calculated |
Bitbucket (PRs, Issues) | Calculated |
Azure DevOps (PRs, Issues) | Calculated |
JIRA (Issues) | Calculated |
ClickUp (Issues) | Calculated |
Trello (Issues) | Calculated |
Reporting Use Cases
The Review Rejected At field is a key timestamp that marks the first time a reviewer requested changes on a pull request. It signals a critical moment in the development lifecycle: the beginning of the first rework cycle. This makes it essential for measuring how often work needs revision and how long the initial feedback loop takes.
Measuring "Time to First Rejection": This field allows you to calculate how long a pull request was in development and review before it was first flagged as needing changes.
You can measure this with the custom formula
(review_rejected_at - LEAST(created_at, first_commit_at)) / DAY(). A short duration might indicate a very efficient and fast-paced review culture, while a long duration could suggest that complex PRs are being submitted or that the review process itself is slow.
Calculating the Rejection Rate: The mere presence of this timestamp indicates that a pull request required rework. This allows you to calculate your team's overall rejection or "changes requested" rate.
A custom formula metric like
ROUND(COUNT_IF(IS_NOT_NULL(review_rejected_at)) / COUNT() * 100, 2)will give you the percentage of all pull requests that needed at least one round of changes. Tracking this KPI can help you understand your team's initial code quality and the effectiveness of your development standards.
Filtering for In-Depth Analysis: You can create reports that focus specifically on pull requests that have gone through a rework cycle.
By using a filter where
Review Rejected At is not null, you can create a dataset to analyze the characteristics of PRs that typically require changes. You could then, for example, analyze the average sizeAVG(lines_changed)of these PRs to see if larger pull requests are more likely to be rejected.