More historically accurate burndown charts using events
- Burndown charts as currently implemented, are largely stateless.
- We will introduce a little more state to account for issues added to a milestone in the middle of a milestone. See #6174 (closed).
- But even with that change, burndown charts are mainly stateless. In particular, when you remove an issue from a particular milestone, the burndown chart treats that issue as if it was never part of it.
- We plan to introduce burndown charts into boards. This will allow the scoping of issues to be flexible/customizable based on the board scope/configuration. So instead of bringing scoping to the milestone page (where the burndown chart currently exists), the idea is to bring the burndown chart to the board, which already has a scoping.
- Burndown charts currently do not capture state. In particular:
- If in the past, an issue was part of a milestone, but then subsequently removed that milestone, our current implementation doesn't account for it.
- If in the past, an issue had a certain label, but then subsequently that label was removed, even our burndown chart in board feature (#6864), will not account for it.
- This problem above is not a major problem currently. We have not received any requests (per my knowledge) to have those more accurate burndowns. My suspicion is that teams typically use burndowns during a milestone as the issue counts/weights are burning down. After the iteration is over, they do not care and even if the issue is moved to another milestone, that is okay.
- However, what is a real problem for GitLabbers right now, is the ability to track missed deliverable rates. We have some ongoing work to do this outside of the product. See gitlab-ce#49201 (closed). But eventually we want to solve this inside GitLab. If the burndown chart can account for historical state, then perhaps it can be used to address that particular problem.
- Long-term (we might never need the long-term solution), we entirely use events (&224, &48) to build historically accurate burndown charts.
- In particular, this will solve tracking missed deliverables for GitLabbers. You would look at a burndown chart, and be able to see (given a particular scoping of labels and other attributes), how many issues that were open at the beginning of the milestone, and how many were closed at the end of the milestone. So you can capture the missed deliverable rates immediately from there.
- In the first iteration, we only use milestone events for historically accurate milestones. This will probably be enough for GitLabbers to track missed deliverables rate, since our team/product area labels are unlikely to change significantly for issues.
- In the second iteration (which we might not need), we consider label events, and make that accurate.
- In iterations after that (again, which we might not need), we consider weight events, assignee events, etc.