Draft: Add ChartData class
Background
To track the progress of the issues assigned to a timebox such as Milestone or Iteration, a burnup/down chart is often used and in GitLab, we have the Milestone/Iteration report feature like shown here.
In the above milestone report, three issues were assigned to the milestone on Mar 20 and one of them was completed. Similarly, if the issues have weights, we are interested in knowing how many weights have been completed. Such data points are currently generated by TimeboxReportService class. For example, for Mar 20
given some milestone (or iteration) we would have the following data point:
{
date: Mar 20,
scope_count: 3, # the number of issues in the milstone
scope_weight: 10, # the sum of the weights of the issues in the milestone
complete_count: 1, # the number of closed issues in the milestone
completed_weight: 2 # the sum of the weights of the closed issues in the milestone
}
What does this MR do and why?
The problem is TimeboxReportService
is a very complex class with many responsibilities and is hard to refactor and update.
This MR adds a new utility class ChartData
that can generate data points used to plot burnup and downcharts.
-
For now,
ChartData
won't be used by any production code but I plan to use it to shrink and refactorTimeboxReportService
in a later MR. -
ChartData
prevents double counting issue and its child tasks as specified in 381879#proposal.
ChartData
work?
How does To generate a data point like the example shown earlier, we need to use a snapshot of the states of the issues and work items on some date for a timebox.
Here's an example snapshot.
[
{
item_id: 1,
timebox_id: 2,
weight: 3,
start_state: ResourceStateEvent.states[:opened],
end_state: ResourceStateEvent.states[:closed],
parent_id: nil,
children_ids: Set.new
},
]
In the snapshot, we find that the item with item_id: 1
became closed and has weight 3.
The generated data point would be:
{
scope_count: 1,
scope_weight: 3,
complete_count: 1,
completed_weight: 3
}
The added specs deal with a comprehensive set of scenarios and have additional inline comments.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.