Use timezones for Danger Reviewer Roulette implementation
What is the productivity problem to solve?
Reduce the mean time to review and mean time review to merge for the GitLab project by using timezones for the the reviewer selection process.
- Reviewer selection chart: https://app.periscopedata.com/app/gitlab/572770/WIP---Development:-Cycle-Time?widget=8331524&udv=906713
- Maintainer selection chart: https://app.periscopedata.com/app/gitlab/572770/WIP---Development:-Cycle-Time?widget=8331541&udv=906713
Problem identification checklist
-
The root cause of the problem is identified. -
The surface of the problem is as small as possible.
What are the potential solutions?
- Retrieve users' timezones from Slack (see #121583 (closed)).
- One of those two things:
- Pick reviewers in my timezone to improve cycle-times between reviewers and authors
- Extra-clever: Pick reviewers near the beginning of their workday regardless of their timezone1
-
All potential solutions are listed. -
A solution has been chosen for the first iteration: PUT THE CHOSEN SOLUTION HERE
Verify that the solution has improved the situation
-
The solution improved the situation. - If yes, check this box and close the issue. Well done!
🎉 - Otherwise, create a new "Productivity Improvement" issue. You can re-use the description from this issue, but obviously another solution should be chosen this time.
- If yes, check this box and close the issue. Well done!
1 Picking reviewers near the beginning of their day would allow the shortest possible turnaround time between author and reviewer on the first cycle only. Further back-and-forth could have just as long of a cycle time (depending on who is chosen). The utility of this solution depends on whether the most common number of review cycles is ~1 or >1.
Edited by Rémy Coutable