My organisation recently moved to GitLab and stared using it as a project management platform. Using milestones, we are starting to see the same behaviour as described in this topic. We often do fast milestones on several (smaller) projects. The most common use-case for us, is to begin work on a milestone the same day as it is defined (and here, I mean both the milestone and corresponding issues). Effectively, this means that we will get incorrect information in the burndown chart, on most of our work, unless we want to introduce latency in our work pipeline in order for this mechanic to "catch up".
Seeing that this is planned to be fixed in %12.2, means that we'll most probably have to look into alternatives, e.g. some string on a board, like the cavemen we are forced to be .
A trial customer who was evaluating this feature encountered what I suspect is this issue. Issues are only showing up on the chart on the day after the issue was opened for them. (Zendesk link, internal only)
I've started to look into this out of interest and curiosity.
My general approach is to move the chart data generation from the backend to the frontend, so JavaScript's dateFormat can take care of the viewer's timezone.
Does this mean that events are not a reliable source of populating chart data? I'm concerned that if I solely use events, after 2 years the charts will no longer show anything.
Also, are events always created when an issue is opened, reopened and closed? Is it possible that the issue's state can change but no event is created (modifying using API for example)?
I was also thinking that system notes can be used for the same purpose, although I am hesitant since I don't think they were meant to be used that way at all.
@smcgivern : @weimeng is a new support engineer at GitLab and has told
me he may be interested in contributing every now and then. Do you mind looking at his questions here and responding if there are immediate answers per your knowledge? If it’s not clear right away and needs further time to investigate that’s fine and we could schedule that later to look further.
@weimeng I'm not sure we can reliably use system notes or events here One option might be to use events if they exist, otherwise fall back to the current method.
@victorwu Thanks for the introduction! I've been working together with @smcgivern and a few others on another MR and everyone has been very helpful. :)
Burndown already needs events table to be displayed correctly, so it should be ok to join events.created_at when issues gets opened and reopened like we already do when they are closed.
Also, are events always created when an issue is opened, reopened and closed? Is it possible that the issue's state can change but no event is created (modifying using API for example)?
This needs further investigation, but an event should be created on these actions.
There is another issue that plans to make burndown charts more tied to events to make it more accurate https://gitlab.com/gitlab-org/gitlab-ee/issues/6903, for example, adding an entry to events table when an issue is assigned to a particular milestone, but this seems out of the scope of this issue.
My concern with this approach is that we'll be returning a lot of data from the backend. Basically all issue events for that milestone.
Another possible approach is to send the browser's timezone with the request and then we can offset the time in SQL so that the aggregates are computed correctly.
Here's what I tried as I'm working on this at !10328 (merged):
Instead of Rails passing the final data to the chart, I'm passing the raw issue data: { created_at: x, weight: x, action: x}
I use JavaScript to convert the timestamps into the client's local timezone, then aggregate into the final chart data
I'm using issue.created_at for issue opened events, as we don't create an event for issue creation
I'm using event.created_at for issue reopened and closed events, as we already do this
@engwan has been helping to review my MR, thanks for that!
%11.10 currently has about 1,000 issues. From a payload size perspective I think it's relatively negligible, but I'm not sure about the database performance and client-side processing load. Any tips on investigating the impact on those fronts?
Also, if we continue down this path, we'll probably want to get the burndown chart to fetch the data from an API or GraphQL endpoint instead of rendering the data in the view as JSON.