Dataset: Issues & Pull Requests
Entity: Pull Requests, Issues
Field ID: review_requested_at
Type: Datetime
Description: The datetime at which the pull request review was first requested. For issues, it is the timestamp of the oldest request across all resolving pull requests.
Source: Calculated
Transformation logic:
Pull requests: It is the datetime of the first
review requestedevent, which happens when a reviewer is assigned for the first time.Issues: it is the datetime of the oldest request for 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 Requested At field is a fundamental timestamp that marks the handoff from development to review, capturing the moment a pull request is first submitted for feedback. It is the starting point for the entire review process, making it essential for measuring both the initial coding duration and the responsiveness of your review team.
Calculating Coding and Idle Time: This field serves as a crucial boundary between the coding and review phases of your cycle time.
Coding Time: It marks the end of the initial development sprint. You can calculate the duration of this phase with the custom formula
(review_requested_at - LEAST(created_at, first_commit_at)) / HOUR().Review Idle Time: It marks the beginning of the time a pull request waits to be picked up. The formula
(first_review_submitted_at - review_requested_at) / HOUR()calculates this idle time, which is a key indicator of bottlenecks in your review process.
Filtering for Actionable Queues: You can use this field to create a real-time list of all work that is waiting for a reviewer.
By creating a report with a filter where
Review Requested At is not null and First Review Submitted At is null, you can build a "To Review" queue for your team, ensuring that no pull request gets forgotten.
Analyzing Review Pipeline Throughput: By using this field as a dimension, you can track the volume of work entering your review pipeline over time.
A line chart with
YEAR_MONTH(review_requested_at)as the dimension andCOUNT()as the metric will show you how many pull requests are being submitted for review each month, helping you to forecast and manage your team's review capacity.