## Summary As part of our migration to the [work items framework]() we will create parity with the Epic `start date` and `due date` on work items where the [inherited](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#start-and-due-date-inheritance) dates are obtained from child issue records. In this work effort, we will **not** modify the existing inheritance logic and epic dates will only consider milestone dates of descendant issues. ## Future Opportunities In a future effort post epic-migration, we will explore [expanding this date logic](https://gitlab.com/gitlab-org/gitlab/-/issues/389446) to also consider iteration dates, issue start date and issue end date. Further, we will [explore](https://gitlab.com/groups/gitlab-org/-/epics/8194) improving the epic start and end date feature by tracking both planned and actual delivery dates in order to identify [drift in plans](https://gitlab.com/gitlab-org/gitlab/-/issues/231511). ## Fixed vs. Inherited usage metrics _copying data from [this comment](https://gitlab.com/gitlab-org/gitlab/-/issues/424544#note_1629238970) for reference_ This is for gitlab.com, on epics that have been created or updated in the past year. | Metrics | Percentage (%) | |---------|-------| | Total number of epics | 100.00 | | Total with fixed start date | 26.23 | | Total with fixed due date | 26.62 | | Total with fixed start and non-fixed due date | 2.51 | | Total with non-fixed start and fixed due date | 2.31 | | Total with fixed start and fixed due date | 23.18 | | Total with non-fixed start and non-fixed due date | 36.14 | ### Migrating data In the new widget, users will set a Fixed or Inherited option that applies to both fields, rather than have that as an option for each individual field. Since this is different from the legacy experience (users can set Fixed/Inherited per field), we will need to have rules set for how to handle migrating data. #### Rules | Old Setting | Legacy Example| New Setting (for both) | Notes | | ------ | ------ | ------ |------ | | Both Start & Due dates Fixed | Start date (fixed): 2024-01-01 <br> <br>Due date (fixed): 2024-12-01 |Fixed | | | Both Start & Due dates Inherited | Start date (inherited): 2024-01-01 <br> <br>Due date (inherited): 2024-12-01 |Inherited | | | One date is Fixed, other Inherited (Fixed date **does not** have value of `None`) | Start date (fixed): 2024-01-01 <br> <br>Due date (inherited): 2024-12-01 | Fixed |The field that was previously Inherited will have a value of `Fixed:None` | | One date is Fixed, other Inherited (Fixed date **does** have value of `None`) | Start date (fixed): none <br> <br>Due date (inherited): 2024-12-01|Inherited |The field that was previously Fixed will have whatever the Inherited value is (could be a date or `None`). | | Start date is after Due date where Start date is `fixed`| Start date (fixed): 2025-01-01 <br> <br>Due date (inherited): 2024-12-01|Inherited| Set the start date to the actual inherited value.| | Start date is after Due date where Start date is `inherited`|Start date (inherited): 2025-01-01 <br> <br>Due date (fixed): 2024-12-01|Inherited| Set the Due date to the actual inherited value.| :warning: In the case where we still could have start date being after the due date (ex. if the milestones only have one of the dates), Inherited due date will be fetched from either the latest due date of the children epics, or the latest milestone due date of the epic children issues, that is after the epic start date. <details><summary>Illustration showing some examples</summary>  </details> #### Feature flag `work_items_rolledup_dates`