Dataset: Issues & Pull Requests
Entity: Pull Requests, Issues
Field ID: last_commit_before_first_review_at
Type: Datetime
Description: The datetime at which the first submitted pull request review was created. For issues, the timestamp is evaluated from resolving pull requests.
Source: Calculated from commits and pull request reviews
Transformation logic:
Pull requests: The
committed_attimestamp of the last commit before the first review was submitted (committed_at <= first_review_submitted_at).Issues: the earliest
last_commit_before_first_review_atfrom 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) | Calculated |
Azure DevOps (PRs, Issues) | Calculated |
JIRA (Issues) | Inferred from PRs |
ClickUp (Issues) | Inferred from PRs |
Trello (Issues) | Inferred from PRs |
Reporting Use Cases
The Last Commit Before First Review At field is a high-precision timestamp that pinpoints the exact moment a pull request was "code complete" before the initial review cycle began. It is an essential marker for accurately isolating the initial, uninterrupted coding phase from any subsequent rework.
Accurately Calculating Initial Coding Time: This field's primary purpose is to serve as the definitive end of the initial development sprint.
You can measure the "pure" coding time with the custom formula
(last_commit_before_first_review_at - LEAST(created_at, first_commit_at)) / HOUR(). This metric is more precise than usingLast Commit Before First Review Atas the end point, as it represents the time taken to produce the first version of the code, independent of how long it waited for review.
Measuring Rework Time: By comparing this timestamp to the last_commit_at, you can effectively isolate and measure the amount of time spent on rework and revisions that occurred after the first review.
The formula
(last_commit_at - last_commit_before_first_review_at) / DAY()calculates the duration of the "rework phase". A high value here indicates that pull requests frequently require significant changes after the initial review, which could point to a need for clearer initial requirements or more thorough initial development.
Identifying Stalled Pull Requests: You can use this field to find pull requests that were pushed for review but have been sitting idle without any feedback.
A report filtered where first_review_submitted_at is null and
Last Commit Before First Review At before 3 days agowill create a list of all PRs that have been waiting for their first review for more than three days, helping you identify and unblock bottlenecks in your review pipeline.