Redefine the coding phase of Cycle Analytics to align with 'GitLab Flow' and 'WIP-MRs'
Problem to solve
Cycle analytics doesn't work well with WIP-MRs. If one follows gitlab flow as described here: https://about.gitlab.com/solutions/gitlab-flow/ , one needs to open a merge request WIP when one starts to work on an issue.
In cycle analytics, the code
phase is defined as "the time between pushing a first commit (previous stage) and creating a merge request related to that commit."
This means that, if one follows what gitlab describes, the code phase will always show ‘not enough data’, since the MR is always earlier than the first commit…
Intended users
Any developer, owner or maintainer who wants to check cycle analytics
Further details
Cycle Analytics should align with the proposed workflow as described in the link above: Create a MR (WIP) first, and only afterwards, start coding. Or: the MR is created before coding/the first commit. That's why the coding phase doesn't seem to have any (wrong) data.
Proposal
The timings have to be defined differently, or the timings should allow for more 'cases':
Defining the coding phase as "the time between starting the MR WIP and removing WIP from the MR" would result in right timings. That's the time you are actually coding: the moment you start, you make a MR WIP, when you're done, you remove the WIP from the MR. (GitLab has buttons to make the MR WIP and to remove the WIP from the MR, so it really would be logic to align cycle analytics with this logic.)
Permissions and Security
No special permissions as such... it's a matter of redefining the 'coding phase' of cycle analytics.
Documentation
What does success look like, and how can we measure that?
The coding phase doesn't have 'not enough data' when one uses the flow as proposed: https://about.gitlab.com/solutions/gitlab-flow/
Links / references
see also: https://support.gitlab.com/hc/en-us/requests/117516