[Metrics] Common Metrics - Review Cycle Duration within a Change Request

[xiaoya-yaya]

Description:

• The duration of a review cycle within a single change request.
• This metric provides maintainers with insight on: Code review process decay, as there are more iterations and review cycle durations increase. Process bottlenecks resulting in long code review iterations.

Filters

• Average or Median Duration

optionally filtered or grouped by:

• Number of people involved in review
• Number of comments in review
• Edits made to a change request
• Project or program Organization making the change request
• Time the change request was submitted
• Developers who contributed to a change request
• Change request
• Number of review cycle on a change request

Instances of Implementation Review Cycle Duration is measured as the time length of one review cycle within a single change request. The duration can be calculated between:

• The moment when each review cycle begins, defined as the point in time when a change request is submitted or updated.
• The moment when each review cycle ends, either because the change request was updated and needs a new review or because it was accepted or rejected.

Resource

• CHAOSS: Common Metrics -> When
• link: https://chaoss.community/metric-review-cycle-duration-within-a-change-request/

[open-digger-bot[bot]]

This issue has not been replied for 24 hours, please pay attention to this issue: @sunshinemingo @wengzhenjie

[frank-zsy]

I think it is hard to identify a change request review cycle with GitHub event data, and even I think review cycle is not a quite objective description, like how can we judge several conversations combination is a review cycle or not?

[xiaoya-yaya]

There is indeed no clear definition regarding what a "review cycle" is. From my understanding it refers to the duration from a new change being requested to the requested change being resolved, which is indeed hard to be implemented based on the data we have now.

[frank-zsy]

Yes, the review resolve is not an event in the GitHub events data, so maybe we can not implement this one shortly, so I will close the issue for now, and maybe we can raise another issue if we have enough data for this.