Gitlab Due Date inheritance

Does anyone know of a place in the documentation that describes the algorithm for Due Date inheritance among milestones / iterations / issues / child epics / parent epics?

Hi @dingerj ,

While there isn’t a specific section in the documentation that describes the entire algorithm for due date inheritance, I can provide you with an overview and direct you to the relevant sections in the documentation.

Milestones:

A milestone represents a time-bound event, like a release or delivery. It can have a start date and a due date. Milestones can be associated with issues and merge requests. The due date for a milestone isn’t automatically inherited by the associated issues or merge requests. You can read more about milestones in the Milestones documentation.

Iterations:

Iterations are timeboxes used to plan and track work on a regular cadence, like sprints in Scrum. An iteration has a start date and a due date. Iterations are scoped to a group and can include issues from projects within that group. The due date of an iteration doesn’t directly influence the due date of associated issues. You can find more information on iterations in the Iterations documentation.

Issues:

Issues have their own due dates, which are independent of milestones, iterations, or epics. You can manually set a due date for an issue when creating or editing it. The due date of an issue isn’t automatically inherited from its associated milestone or iteration. Check the Issues documentation for more information.

Child Epics / Parent Epics:

In GitLab, epics can have start and due dates, and they can be manually set. The start date and due date of a parent epic aren’t automatically inherited by its child epics. However, an epic’s start date and due date can be automatically calculated based on the earliest start date and the latest due date of its associated issues and child epics. You can enable this option in the epic’s settings. You can read more about epics and their date handling in the Epics documentation.

In summary, due dates in GitLab are mostly set independently for milestones, iterations, issues, and epics. However, epics can have their start and due dates automatically calculated based on their associated issues and child epics.

I hope this overview helps! If you need more information or have any other questions, feel free to ask! :blush:

Thanks for your response. I had read those parts of the docs, and have not been able to explain the date behavior I see based on the descriptions. I was hoping to find somewhere that says which due date (among the options of Milestone, Issue, Iteration) has the highest priority to “inherit” up to epics.
Secondarily, even if I only use one option (only coding due date on Milestones) I see inconsistent behavior in terms of the latest date only sometimes inheriting to a parent epic. (But I’m new enough to the tool to suspect user error.)