Burndown charts look really weird because of legacy data
Resources
PM @victorwu | BE @felipe_artur | UX @pedroms
Problem
- We deployed burndown charts in 9.1 with (https://gitlab.com/gitlab-org/gitlab-ee/issues/91).
- The feature depends on issues having a
closed_at
attribute (https://gitlab.com/gitlab-org/gitlab-ce/issues/27212). This value is recorded when an issue is closed. This can only happen to issues after the 9.1 release of https://gitlab.com/gitlab-org/gitlab-ce/issues/27212. - Currently, for the CE 9.1 burndown chart, we don't see it "burning down", because most of the issues were closed prior to the release, and therefore, they don't have a
closed_at
value. As a result, the burndown chart still considers them open. - This will not impact issues that are closed after 9.1 is released.
Proposed solution
- If an issue does not have a
closed_at
value, do not consider it in the burndown chart calculation. It is better to not have the issue be considered, than it to be considered and stuck and never "closed" from the perspective of the burndown chart.- The resulting impact is that old milestones will just have flat lines at zero versus flat lines at some finite number.
- Add an alert explaining this nuance (“More information” links to the documentation). This will help when the feature is released and people are confused looking at old milestones:
- If some of the milestone issues were closed before the 9.1 update:
- If all of the milestone issues were closed before the 9.1 update; also hide the burndown chart is entirely:
Edited by Coung Ngo