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 thatmilestone-start-date <= d <= milestone-end-date
, which we only care about for the purpose of generating the chart. Note thatd
has no relation tonow
. 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
, theni
was necessarily closed oni.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 assumei
was opened oni.closed_at + 1 day
. So do count/weight it. - If
d == i.closed_at
, then assumei
was closed for that whole day ofd
. So do not count/weight it. - If
d < i.closed_at
, then assumei
was open ond
. So do count/weight it.
- If
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
New/edit milestone | Empty state (feature discovery) | Expanded sidebar | Collapsed sidebar |
---|---|---|---|
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.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.