On the roadmap view, we should allow a user to view the details of the start and due dates of an epic.
The timeline already shows the dates. But this is approximate, especially if you have a very long length of time on the screen, it is hard to know the exact start and end dates.
If a user wants to quickly drill down on an epic and know the exact start and end dates, they should be able to do so, without clicking through to the epic. They should be able to see it on the roadmap view itself.
We can now also have fixed dates versus inherited dates for an epic. So we should also indicate this in the roadmap view. So again, the user can know this information without having to click through to the epic. They can see it on the roadmap view itself.
In the mockup below, a user mouses over the epic, and this information is shown. Even before mousing over, we can use colors to indicate whether the start date and end date are fixed vs inherited.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@kokeefe Why is it important to know if an epic has dates that are fixed vs inherited? It is because inherited dates may change impacting your roadmap items?
We need to represent the dates the work be in progress, we currently can only infer this by the Start and End dates given in the epic. We also have a 3rd ... the Due date which we need to represent (for example, if the end date is after the due date), but that is covered via (#7071 (closed)).
As we are going to show milestones on the roadmap as well (#6802 (closed))... we may not need to show the 'inherited by milestone' text. Perhaps when you hover over the epic we get vertical lines that match with the milestone as displayed on the roadmap (similar to above)
I still wonder why it matter if a date is inherited vs fixed, can ya explain @kokeefe ? What is a user missing just seeing end date vs end date = inherited OR fixed?
I think for MVC something along the lines of the proposal makes sense. We show the dates on hover. If we want to call out inherited perhaps we could use the icon or just text there. If a date is out of view it stacks. The last view to figure out would be if the epic bar fills the entire screen.
@uhlexsis I'd say, the date is what matters most.
An inherited date is probably more accurate, as it is being pulled from a collection of dates, and showing the last one. A fixed date is more arbitrary.
We show the dates on hover. If we want to call out inherited perhaps we could use the icon or just text there.
@uhlexsis I like that dates can be inherited. It should make roadmaps more robust and reduced mistakes and errors.
On the other hand, calculated dates (starts, ends) have two impacts:
What item is causing a roadmap line to stick at date X while I set "all" items to date Y. It should be shown (hover/popup ?), what element(s) cause a line to start or end at date X. Because a user needs to change these, to move the bar to date Y.
If I change an item of date X to Y, it should warn or give a hint, that an epic bar will be resized. This might be recursive, because it might cause multiple epics to move.
In MS project it's clear to see, if I change an item's start / end date, I'll change the bars, but in GitLab, this view isn't side by side, thus the implications of an item's date change will be unclear to the user.
Keanon O'Keefechanged title from View fixed vs inherited start and end dates of epics on roadmap to View fixed vs inherited start and due dates of epics on roadmap
changed title from View fixed vs inherited start and end dates of epics on roadmap to View fixed vs inherited start and due dates of epics on roadmap
Adding a milestone indicator to the left column to indicate if an milestone has been inherited. Hovering triggers a tooltip with more information.
In the epic popover, the date section is expanded to now show if a date is inherited (design is v rough).
I chose to make fixed the default here, and only show an indication if a date has been inherited- as that seems to be the more important and risky of the two types. Open to ideation here.
Do we have data on how many dates are inherited vs fixed?
Do we need to show WHAT milestone is being inherited, or just display that it is inherited? Displaying milestone name and information here gets to be a lot of information to digest, especially with long milestone names. We can get clever and try to truncate etc but then it negates having that information displayed in the first place, and gets hairy if we have tooltips on popover etc. Showing it within the row also breaks when an epic fills the entire view of the roadmap (you can see Jira has a similar problem below)
On #6802 (closed) I mention triggering a "milestone guide line" on hover of a milestone. Maybe this could alleviate things?
Do we have data on how many dates are inherited vs fixed?
Not that I am aware of, I can dig.
Do we need to show WHAT milestone is being inherited, or just display that it is inherited? Displaying milestone name and information here gets to be a lot of information to digest, especially with long milestone names. We can get clever and try to truncate etc but then it negates having that information displayed in the first place, and gets hairy if we have tooltips on popover etc. Showing it within the row also breaks when an epic fills the entire view of the roadmap (you can see Jira has a similar problem below)
Just show it is inherited for now.
On #6802 (closed) I mention triggering a "milestone guide line" on hover of a milestone. Maybe this could alleviate things?
@cablett Would you mind helping to break this down on the backend?
The roadmap GraphQL response for each epic currently includes startDate and dueDate. We'll also need to be able to surface the source of inherited dates, if any, for each epic. The source can be a child epic or a milestone.
@uhlexsis@kokeefe What happens if the startDate and dueDate are inherited from different milestones? Will there be two clock icons and separate tooltips?
Sure, but we should only display the earliest and latest dates, even if they are from diff milestones. I don't think we need 2 icons or tooltips. We should combine it all into a succinct message.
we should only display the earliest and latest dates, even if they are from diff milestones
That makes sense to me as well @kokeefe as that milestone/object is what the date is directly inherited from. Is there something we are not accounting for here @johnhope ?
@uhlexsis@kokeefe That's everything I think, sorry for the confusion. Just checking that the one tooltip message should account for both sources. In the GraphQL we'll return a single source for startDate and a single source for dueDate.
I initially thought about cacheing the values - not sure if that is covered yet and I'm still reading through all the comments in !14366 (merged). If the query is exponential or otherwise expensive we could consider it.
In the simpler case, the backend work would involve exposing something like start_date_sources and due_date_sources in the GraphQL schema, which could be either one or more Milestones or an Epic. This abstract source type would have common fields - id, title. I wonder, though, if that's introducing some inappropriate polymorphism?
As far as I can tell from here (somewhat of an incomplete analysis tbh), it's not overly complex, but I want to make sure that I'm not oversimplifying
edit: in the case of multiple milestones (as above) this does get more complex
inherited source is stored in epics db for each record. For start date on if one of the 2 is not null then date is inherited start_date_sourcing_milestone_id, start_date_sourcing_epic_id and for due date due_date_sourcing_milestone_id, due_date_sourcing_epic_id
This abstract source type would have common fields - id, title.
I think you may want the type: milestone or epic as well, just title might not be enough to actually display where the date is coming from.
in the case of multiple milestones (as above) this does get more complex
In case of multiple milestones the source milestone should still pick one(first) of the milestones with same dates, if that happens.
@cablett Sorry if I introduced confusion here. We should only be returning one source for each of start_date and due_date, rather than multiple sources. Does that make sense?
Thank you so much for the context @acroitor and @johnhope ! That MR really is complex - nice work @acroitor! <3
So if we expose title, id, iid and type that would probably be sufficient. :) I'll be working on this issue so I'll be the one dealing with the accuracy of that statement
We should only be returning one source for each of start_date and due_date, rather than multiple sources
Hmm, I now realize that multiple milestones will make epics relate to widest range milestones. So let's say there are quarterly Release type milestones and monthly Sprint type milestones. If an epic has a related issue that has both milestones types, then epic boundaries would always be the boundaries of the Release milestone. So if for an epic all its issues start in last Sprint(3) of Release 1 and end in first Sprint(1) of Release 2 the epic boundaries would still appear as Release1#start_date - Release2#end_date, way bigger than in reality
I think this is where I was getting my wires crossed - thinking we'd have to handle all the cases where we'd have 'wider scope' milestones that may need to be taken into account and shown
I now realize that multiple milestones will make epics relate to widest range milestones.
I wonder if we considered "shortest" range instead? As a user, I think shortest range would make more sense - if issue belongs to multiple milestones (time frames), shouldn't be start/due date set from "intersection" of all these milestones?
e.g. if an issue belongs to milestones: Dec 1 - Dec 10, Nov 1 - Dec 30, Dec 5 - 30 I would expect that real start/due dates would be Dec 5 - Dec 10.
I tried to present how it will work with current inherited dates calculation, without any change, I think
And the question is if that would still be acceptable as a first iteration?
shouldn't be start/due date set from "intersection" of all these milestones
Not sure if this is the place to go deeper into implementation details, but I don't think intersection of all milestones would work in all cases TBH. Lets take for instance following example: Epic 1 has IssueA and Issue B. Issue A is part of Dec 1 - Dec 10 milestone and Nov 1 - Dec 30 and Issue B is part of Dec 5 - Dec 20 and Nov 1 - Dec 30, then epic start/due dates would be Dec 1 - Dec 20, which is not a simple intersection of the milestone dates.
Currently for a given epic we get all related milestones through epic_issues and then get the min(start_date) and max(end_date) from the obtained list of milestones.
I think with multiple milestones for each issue we would need to first get a single milestone for start_date, with start_date = max(start_date), then a single milestone for due_date with due_date = min(end_date) from all issue's milestones and then from the obtained list of milestones get the min(start_date) and max(end_date). I'm wondering if we can get the first part done with a lateral join and how would that affect performance as theoretically the list of issues linked to an epic is unlimited.
Lets take for instance following example: Epic 1 has IssueA and Issue B. Issue A is part of Dec 1 - Dec 10 milestone and Nov 1 - Dec 30 and Issue B is part of Dec 5 - Dec 20 and Nov 1 - Dec 30, then epic start/due dates would be Dec 1 - Dec 20, which is not a simple intersection of the milestone dates.
I meant intersection of milestones for single issue which then can be used for getting epic start/due dates as you described.
Issue A is part of Dec 1 - Dec 10 and Nov 1 - Dec 30 milestones
Issue B is part of Dec 5 - Dec 20 and Nov 1 - Dec 30 milestones
I'd expect to see the inherited Epic dates on the roadmap to be Nov 1st (as that is the first start date of work in the epic) and Dec 30th (as that is the latest due date assigned to work in the epic).
@cablett's call out above is true, that a Release or Quarterly milestone would cause the Epic to map to the whole quarter. @uhlexsis thoughts here?
What is the purpose of our due dates in issues? How are they reflected in roadmaps and how do they interact with the issue dates?
Why don't we allow a user to choose their own manual dates vs inherit for their issues like we do for epics?
How many milestones would a user want an issue to inherit dates from?
Always only one? Flexible?
If users could set one milestone type as the one that all issues inherited dates from- how would this impact the product? Would this work? IE: Issues in GitLab group always inherit their date from sprint. The problem I see here would be if an issue doesn't have sprint defined, in which case I guess it is the same as an issue having no milestone currently.
If we allow users to define which milestone(s) from which to inherit from, what would the default be?
It seems that we would want the dates to inherit from the working cycle, not just any milestones it may relate to, but we don't really define working cycle and allow it to behave as such even if we are going to allow users to sort of define them with milestone types.
Perhaps when we let users define a milestone from which that the issue will inherit dates, we give them the option to define WHICH it is inheriting from? Or in the future when a user is creating milestone types, they pick which type defines date inheriting?
Picking which milestone to inherit from
Choosing a default in milestone types
-
Another option would be breaking working cycle (or whatever we call it) away from the milestone groups and into its own area. The issues would then inherit dates from this. The problem here though, would users want to choose more than one milestone (ie they are actually wanting the date to inherit from the working cycle AND some other milestone they have defined)?
A monster mash of these options would be allowing a user to either choose their own dates for the issue (if this makes sense), or select that they want the issue to inherit from the milestones and THEN select which milestones it should inherit dates from (could be just one or all 5?). This is pretty similar to epics.
I throw my 2 cents here, please feel free to correct me as these are my personal assumptions without solid background.
My understanding is that we do not need issues to inherit dates from milestones because we can just assign milestones to the issue, so it is fairly clear what is the timeframe for the given issue, plus due date if that issue needs to meet a more strict date. I do not know the historical reason for introducing inherited dates for epics, but I am assuming it was done because epics are not directly linked to milestones, so we need a way to show how the epics span over time?
@acroitor We previously allowed you to have sub epic dates that existed outside the parent epics set dates, creating a scenario where the Parent Epic's timeline was incorrect. Epic Date Inheritance (#7332 (closed)) primarily was introduced to resolve this for users by providing the ability to inherit children's set dates, so the Parent Epic represents the true estimated timeframe of work.
Due dates enable customers to set a specific date for an issue to be completed, generally due to it being a blocker or important set of work in a sequence of work.
How are they reflected in roadmaps and how do they interact with the issue dates?
Currently issues and their individual dates don't display in a roadmap. We hope to get to this soon.
Why don't we allow a user to choose their own manual dates vs inherit for their issues like we do for epics?
We currently allow for you to choose a manual Due date for an issue. As @acroitor mentioned above Issues have milestones assigned to them, setting their date range and displaying it over a hover in sidebar. Due date allows you to set a more specific earlier end date for the work, within a milestone
How many milestones would a user want an issue to inherit dates from?
I'd imagine a flexible number, this should be discussed in relation to #5135 (closed), perhaps a call?
If users could set one milestone type as the one that all issues inherited dates from- how would this impact the product? Would this work? IE: Issues in GitLab group always inherit their date from sprint. The problem I see here would be if an issue doesn't have sprint defined, in which case I guess it is the same as an issue having no milestone currently.
This should also be discussed in relation to #5135 (closed)
If we allow users to define which milestone(s) from which to inherit from, what would the default be?
Default maybe should be none? or possibly a setting when you define a milestone per #5135 (closed)
There's not much more breakdown needed on the frontend. Majority of work on this one will lay on the backend. I'm good with moving to workflowready for development once @johnhope is.
@kokeefe You'd mentioned Release/Quarterly milestones causing the epic to span the whole quarter in #7076 (comment 254805686). If you're happy that's not an problem then we can press ahead.
So we're on the same page, start date should inherit from the earliest-starting associated milestone and due date from the latest-ending milestone, regardless of the length of either, is that right?
^ @johnhope that does concern me. @hollyreynolds@uhlexsis im curious if you have had any additional thoughts here. The only solution I can think of is choosing which type milestones to inherit from, as they are defined by users via #5135 (closed) ?
If we wanted to do the most basic thing possible, I'd think most MVC would be not allowing users to inherit dates while we sort this out. Probably not the direction you want to go though.
If we wanted to iterate a bit more- This is kind of what I am thinking @kokeefe . It doesn't seem like a trivial effort though. I wonder if this is kind of blocked by #5135 (closed)?
Those two date options really shouldn't be exposed to users at the same time (those radio buttons). It makes it very confusing as to what edit means. We could alleviate this a bit by making choosing the date type the first step in the flow for a user to pick, and that impacts the view they see and what they are editing in the sidebar. I did this here with the segmented control (basically tabs).
Now that it is very clear what edit is actually impacting, if a user has selected inherited and clicks edit, they get a dropdown that allows them to choose which milestone they want to inherit from.
If a user selected the fixed date option, the experience is similar to how it is now.
@uhlexsis So long as we don't have to load the available dates until the user clicks 'edit' it looks great to me!
Since #5135 (closed) is still in workflowdesign we could make a start on this just for the existing single-inherited milestone. Then we could support listing milestones associated with the issues in the epic (a list of one, basically), leaving very little work to do to support multiple milestones when #5135 (closed) is done.