Next

Collect milestone events data for burnup and burndown charts. Weight: 3 + 1 = 5(as we do not use weight 4)

Create the resource_milestone_events table. Weight: 1

issue_id	merge_request_id	milestone_id	user_id	action	state	created_at
integer	integer	integer	integer	integer	integer	datetime

• issue_id - FK to issues table
• merge_request_id - FK to merge_requests table
• milestone_id - the milestone(or milestones). We may consider having this field as array of integers in order to support same event triggered on issues with multiple milestones. E.g. if an issue is part of multiple milestones and its weight changes, instead of creating an event for each milestone have the milestone_ids store the values of milestones.
• user_id - User that triggered the event.
• action - one of enum values: Added | Removed | StateChange | WeightChange
• state - issue or merge request state: Open, Closed, Merged. state change events can also be retrieved from the generic events table. I am wondering if it is worth duplicating this data here for performance reasons, rather than having to get it from the events table by joining the resource_milestone_events for given issue or merge_request grouped by created_at date. Perhaps it is worth running some query plans.
• created_at - the date when event was triggered.

Create the issue_weight_events table. Weight: 1

issue_id	user_id	weight	created_at
integer	integer	integer	datetime

Should we be consistent and call this table resource_weight_events ? Although only issues have weights(at least for now).

• issue_id - FK to issues table
• user_id - User that triggered the event.
• weight - weight of the issue, to be able to have the graph not only by count but also by weight. As an idea we may want to store the delta of the issue's old and new weight in order to later easily just sum the weights and get the sum for a specific date.
• created_at - the date when event was triggered.

Note: Table structure is not final, it may require changes during the actual implementation.

Track events on milestone and weight changes for issues and merge requests. Weight: 3

When an issue is created, updated, moved, reopened, promoted to epic, closed, deleted(any other ?) create a corresponding resource_milestone_event or issue_weight_event if any of the issue's milestone or weight changes(consider tracking state if we decide to keep state column within resource_milestone_events)

To consider: given we have about 6M issues, tracking issue changes may generate a big volume of events, so I think we should release this under a feature flag so that we can enable it for gitlab-org first and then perhaps make it available for wider audience ?