Dataset: Reviews
Entity: Pull Request Review
Field ID: requested_at
Type: Datetime
Description: The datetime at which the review was originally requested. NULL if the review was spontaneous.
Source: App
Transformation logic:
The
requested_atis calculated by looking at the date of theREVIEWER_ASSIGNEDevent preceding the review.If two successive reviews are provided by the same reviewer after being assigned for review, the first review will have a
requested_atand the second review will be considered spontaneous (requested_atisNULL)If a reviewer is assigned for review, then unassigned, then provides a review, then the review will be considered spontaneous (
requested_atisNULL)
From: |
|
Github (Reviews) | Calculated |
Gitlab (MRs) | Calculated |
Bitbucket (PRs) | Calculated |
Azure DevOps (PR Threads) | Calculated |
Jira | N/A |
ClickUp | N/A |
Trello | N/A |
Reporting Use Cases
The Requested At field from the Reviews dataset is a crucial timestamp that marks the moment a specific reviewer was asked to provide feedback on a pull request. It is essential for measuring individual reviewer responsiveness and for distinguishing between formal requests and proactive, "spontaneous" reviews.
Measuring Individual Reviewer Turnaround Time: This is the field's most powerful use case. It allows you to calculate how long it takes a specific person to complete their review after being formally requested.
You can calculate this with the custom formula
(submitted_at - requested_at) / HOUR(). Analyzing the average of this metric per reviewer can help identify who is quick to respond and who might be a bottleneck in your review process.
Distinguishing Between Requested and Spontaneous Reviews: This field is the only way to separate formal reviews from proactive ones.
To analyze only the reviews that were formally requested, you can apply a filter where
Requested Atis not null.Conversely, to find all "spontaneous" reviews where a team member jumped in without being asked, you can filter where
Requested At is null. A high number of spontaneous reviews can be a strong indicator of a healthy, collaborative team culture.
Analyzing Review Workload: You can use this field as a time-based dimension to track the volume of review requests being generated and assigned over time.
A line chart with a dimension like
YEAR_MONTH(requested_at)and aCOUNT()metric can show you the number of formal review requests sent out each month, helping you to understand and manage your team's review workload.