Currently timeToReview is calculated as submittedAt - max(publishedAt, commitPushedDate). This means reviewers who are assigned late in a PR's lifecycle get penalized for time they had no awareness the PR existed.
The GitHub timeline API exposes review_requested events with accurate timestamps. Using that as the clock start would make the metric reflect actual reviewer responsiveness.
I verified this against our own org's data. For one reviewer the tool reported 2d 2h 5m. Recalculating from review_requested → first review submission across 114 PRs where the reviewer was explicitly requested: median 6h 26m. The difference is almost entirely explained by PRs that sat open for days before the reviewer was tagged.
The GitHub timeline endpoint is:
GET /repos/{owner}/{repo}/issues/{issue_number}/timeline
Events with "event": "review_requested" include created_at and requested_reviewer.login. You'd take the latest review_requested event for a given reviewer that precedes their first review submission.
Would you be open to adding this as an alternative clock start — either as a new stat or as a configuration option on timeToReview?
Currently
timeToReviewis calculated assubmittedAt - max(publishedAt, commitPushedDate). This means reviewers who are assigned late in a PR's lifecycle get penalized for time they had no awareness the PR existed.The GitHub timeline API exposes
review_requestedevents with accurate timestamps. Using that as the clock start would make the metric reflect actual reviewer responsiveness.I verified this against our own org's data. For one reviewer the tool reported
2d 2h 5m. Recalculating fromreview_requested→ first review submission across 114 PRs where the reviewer was explicitly requested: median 6h 26m. The difference is almost entirely explained by PRs that sat open for days before the reviewer was tagged.The GitHub timeline endpoint is:
Events with
"event": "review_requested"includecreated_atandrequested_reviewer.login. You'd take the latestreview_requestedevent for a given reviewer that precedes their first review submission.Would you be open to adding this as an alternative clock start — either as a new stat or as a configuration option on
timeToReview?