Skip to main content

Issues and PRs > First review submitted at

Tom Williams avatar
Written by Tom Williams
Updated this week

Dataset: Issues & Pull Requests

Entity: Pull Requests, Issues

Field ID: first_review_submitted_at

Type: Datetime

Description: The datetime at which the first review was submitted on a pull request. For issues, it is the timestamp of the oldest review submission 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

  • Issues: It is the submission datetime of the oldest pull request 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)

Inferred from PRs

ClickUp (Issues)

Inferred from PRs

Trello (Issues)

Inferred from PRs

Reporting Use Cases

The First Review Submitted At field is a critical timestamp that marks the end of the initial development phase and the beginning of the formal feedback loop. It is essential for calculating the duration of your team's "coding time" and analyzing the efficiency of the handoff to the review stage.

  • Calculating Coding Time: This field's primary function is to serve as the end point for the initial coding phase of a pull request.

    • You can accurately measure the "Coding Time" portion of your cycle time with the custom formula (first_review_submitted_at - LEAST(created_at, first_commit_at)) / HOUR(). A high value for this metric might indicate that pull requests are too large or that developers face blockers during implementation.

  • Measuring Review Cycle Duration: This timestamp also marks the start of the active review and rework process.

    • You can calculate the time it takes to get a pull request from its first review to final approval with the formula (review_approved_at - first_review_submitted_at) / DAY(). This helps you understand how long the feedback and revision cycle takes.

  • Filtering for Workflow Management: The presence or absence of this timestamp is a powerful way to segment your pull requests by their stage in the review process.

    • To find all open pull requests that have been requested for review but have not yet received a first review, you can use a filter where Review Requested At is not null and First Review Submitted At is null. This helps identify bottlenecks where work is waiting for a reviewer.

Did this answer your question?