As this was one of the main motivations for this project, we definitely need to focus on this :D
The metrics we'll be gathering initially will be
[ ] Time the merge request has been on review (1)
[ ] Pull request author
[ ] Pull request reviewers / approvers
[ ] Merge request intention (2)
[ ] Merge request areas (3)
[ ] Amount of LoC changes (added and removed)
[ ] Amount of comments
[ ] Amount of commits
1) The review time might be tricky to calculate, so we'll need to make some assumptions. I'm proposing the following:
GitHub: The review time will be calculated since the first reviewer has been added until the last reviewer has agreed or the PR has been merged. Draft MRs will be considered unreviewed even if there is a reviewer set (by some automation for example).
GitLab: The review time will be calculated since the first approver has been added until the MR is approved. WIP MRs will also be considered unreviewed even if there is a reviewer set.
2) The intention will be determined by checking the conventional commits commit types. We'll use some heuristics to determine it. I'm proposing the following:
Type
Commits
Maintenance
build | ci | chore | style | test
Bug fix
fix + ((maintenance) | docs)
Feature
feat + ((maintenance) | docs)
Improvement?
refactor | perf + (maintenance)
Documentation
docs
3) Gathered from conventional commits, that's it, no fancy stuff
As this was one of the main motivations for this project, we definitely need to focus on this :D
The metrics we'll be gathering initially will be
1) The review time might be tricky to calculate, so we'll need to make some assumptions. I'm proposing the following:
GitHub: The review time will be calculated since the first reviewer has been added until the last reviewer has agreed or the PR has been merged. Draft MRs will be considered unreviewed even if there is a reviewer set (by some automation for example).
GitLab: The review time will be calculated since the first approver has been added until the MR is approved. WIP MRs will also be considered unreviewed even if there is a reviewer set.
2) The intention will be determined by checking the conventional commits commit types. We'll use some heuristics to determine it. I'm proposing the following:
build
|ci
|chore
|style
|test
fix
+ ((maintenance) |docs
)feat
+ ((maintenance) |docs
)refactor
|perf
+ (maintenance)docs
3) Gathered from conventional commits, that's it, no fancy stuff