Skip to content

Burndown chart

Resources

PM @victorwu | FE @mikegreiling | UX @pedroms

Dependency

As per the technical design,

Description

  • 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 (x icon) OR the “Add start and due date” button. From then on, this information box will no longer appear for that user on any milestone.

Algorithm

  • 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 d has no relation to now. We can be looking at milestones in the past, present, or future.
  • Suppose I am looking at a given issue i that has the associated milestone with it. I only care about issues with this milestone.
  • Consider these scenarios:
    • If d > i.closed_at && i.state(now)==closed , then i was necessarily closed on i.closed_at. So do not count/weight it in the burndown chart as an open issue.
    • If d > i.closed_at && i.state(now)==open, then assume i was opened on i.closed_at + 1 day. So do count/weight it.
    • If d == i.closed_at, then assume i was closed for that whole day of d. So do not count/weight it.
    • If d < i.closed_at, then assume i was open on d. So do count/weight it.

Stretch goals

  • 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.

Weights

  • 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

🔍 Check the design specs (for spacing, sizes, colors and text copying) — Hide notes in the top-right corner

New/edit milestone Empty state (feature discovery) Expanded sidebar Collapsed sidebar
image empty sidebar--expanded image

Dependencies

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.