Improve approach for linking merge requests to issues for cycle analytics calculations
The Plan metric in cycle analytics is not helpful. Once an issue is triaged in some way (Issue stage) is begins the Plan stage, however this consistently shows an impossibly short period of time in GitLab projects, and is likely the same for customers.
Project | gitlab-org/gitlab-ce | gitlab-org/gitlab-ee | gitlab-org/gitaly |
---|---|---|---|
Issue | 6 mins | < 1 min | 2 mins |
Plan | 4 days | 6 days | 7 days |
Also when viewing the list of issues that are being considered, gitlab-ce
and gitlab-ee
report only one issue, while gitaly
says We don't have enough data to show this stage.
The issue is caused by first_mentioned_in_commit_at
only being set if the issue is explicitly mentioned in a commit message.
Proposal
Update first_mentioned_in_commit_at
to be set in the following two situations:
- a commit message is pushed explicitly mentions the issue (existing)
- sets
first_mentioned_in_commit_at
to the authored date of the commit
- sets
- when a merge request is merged and explicitly closes the issue
- sets
first_mentioned_in_commit_at
to the authored date of the first commit in the merge request
- sets
The merge request widget allows issues to be closed by mentioning the issue in a commit message or in the merge request description. The cycle analytics logic should be consistent.