As per the technical design,
- This is an ~"EE Starter" feature.
- Burndown chart of open issues count within a milestone.
- Only show a burndown chart on the milestone page, if the associated milestone has a start date and a due date. If the milestone does not have both, do not show anything.
- x-axis should reflect the milestone period.
- y-axis should be open issues count over that time period.
- If feasible, the chart should be displayed in mobile and tablet views too. Its behavior will have to be evaluated during implementation.
- The empty state (feature discovery) should be shown on milestone pages if those milestones don't have a start date and a due date. It should be shown until the user clicks the dismiss button (
xicon) OR the “Add start and due date” button. From then on, this information box will no longer appear for that user on any milestone.
- Assume all dates/times are with "day" granularity.
- Assume each issue has
closed_at, and it gets updated every time the issue is closed.
- Suppose I am looking at a given day, call it
d, and that
milestone-start-date <= d <= milestone-end-date, which we only care about for the purpose of generating the chart. Note that
dhas no relation to
now. We can be looking at milestones in the past, present, or future.
- Suppose I am looking at a given issue
ithat has the associated milestone with it. I only care about issues with this milestone.
- Consider these scenarios:
d > i.closed_at && i.state(now)==closed, then
iwas necessarily closed on
i.closed_at. So do not count/weight it in the burndown chart as an open issue.
d > i.closed_at && i.state(now)==open, then assume
iwas opened on
i.closed_at + 1 day. So do count/weight it.
d == i.closed_at, then assume
iwas closed for that whole day of
d. So do not count/weight it.
d < i.closed_at, then assume
iwas open on
d. So do count/weight it.
Show an informative tooltip when hovering the chart with the number of open issues for that date (e.g.
22 open issues • Sep 16, 2016).
Burndown chart with cumulative issue weight.
- Design is here: https://gitlab.com/gitlab-org/gitlab-ee/issues/91#note_17765489
- The system just looks at all the relevant issues as before.
- It treats every single issue as having a weight. If no weight is actually assigned, the system just assumes the weight is 0.
- All the calculations are the same. So essentially if you have a zero weight issue, it does not contribute to the burndown chart value.
The system just looks at all the relevant issues as before.
It treats every single issue as having a weight. If no weight is actually assigned, the system just assumes the weight is 0.
All the calculations are the same. So essentially if you have a zero weight issue, it does not contribute to the burndown chart value.
Designs and specs
|New/edit milestone||Empty state (feature discovery)||Expanded sidebar||Collapsed sidebar|
Design and implementation considerations
- The system should generate tick marks on the x-axis and put in dates automatically when the chart loads. We can assume that users are sensible and their milestones are not ridiculous, i.e. designing/implementing for milestones that are at least a few days and go up to several months. The chart should not break if it is out of this range, but it doesn't have to look good in those extreme cases.
- The system should generate tick marks on the y-axis automatically based on the data that makes sense, again for reasonable scenarios. Don't have to worry if somebody decides to put in 1000 issues for a milestone.