Dataset: Issues & Pull Requests
Entity: Pull Requests, Issues
Field ID: review_last_rejected_at
Type: Datetime
Description: The datetime at which a pull request review was last rejected after a review (CHANGES_REQUESTED). For issues, it is the timestamp of the newest rejection review across all resolving pull requests.
Source: Calculated from pull request reviews
Transformation logic:
Pull requests: It is the submission datetime of the last pull request review with the status
CHANGES_REQUESTED.Issues: It is the submission datetime of the newest
CHANGES_REQUESTED' 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 Last Rejected At field is a critical timestamp that marks the most recent time a reviewer requested changes on a pull request. It signals the start of a "rework" cycle, making it essential for measuring the efficiency of your feedback loop and identifying pull requests that are blocked or require significant changes.
Measuring Rework Duration: This field's primary use is to calculate the time it takes for a developer to address feedback and resubmit their work for another review.
You can measure this "rework time" with the custom formula
(last_review_submitted_at - review_last_rejected_at) / DAY(). A high average for this metric could indicate that the requested changes are complex, that requirements were unclear, or that developers are slow to address feedback.
Filtering for Blocked Pull Requests: This timestamp is a clear indicator that a pull request is in a "needs work" state and cannot move forward.
You can create a high-priority list of all open pull requests that are currently blocked by a rejection using a filter where
Review Last Rejected At is not null and Review State = "CHANGES_REQUESTED". Sorting this list by the rejection date can help you prioritize the oldest blocked items.
Analyzing Code Quality Trends: You can track the frequency of rejections to get a sense of your team's initial code quality.
A custom metric like
ROUND(COUNT_IF(IS_NOT_NULL(review_last_rejected_at)) / COUNT() * 100, 2)calculates the percentage of pull requests that require at least one round of changes. A high or rising percentage could be a signal that developers are submitting work prematurely or that coding standards are not being met.