Right now we have an SLO for a reviewer's initial response based on the requested_on timestamp and the current time vs. a limit slo_initial_response defined in the GateType. When a reviewer gives any vote or comment, we set responded_on at that time.
Now, we will also calculate a time for resolution and set resolved_on when a gate becomes NA, APPROVED, or DENIED. That will be compared against a new slo_resolution limit defined in the GateType.
Unlike the initial response, the resolution can be delayed by work needing to be done by the feature owner rather than the reviewers. To track the time spent in the NEEDS_WORK state, we will use new fields needs_work_started_on and needs_work_elapsed.
Steps:
Right now we have an SLO for a reviewer's initial response based on the
requested_ontimestamp and the current time vs. a limitslo_initial_responsedefined in theGateType. When a reviewer gives any vote or comment, we setresponded_onat that time.Now, we will also calculate a time for resolution and set
resolved_onwhen a gate becomes NA, APPROVED, or DENIED. That will be compared against a newslo_resolutionlimit defined in theGateType.Unlike the initial response, the resolution can be delayed by work needing to be done by the feature owner rather than the reviewers. To track the time spent in the NEEDS_WORK state, we will use new fields
needs_work_started_onandneeds_work_elapsed.Steps:
resolved_on,needs_work_started_on, andneeds_work_elapsedand the logic to set them.slo_resolutionlimit.