Feature request: time window

[maxscience]

Hi everyone! Unless I’m missing something, there’s no way now to specify a time window for milestones? Specific example: https://www.starmaps.app/roadmap/github.com/cryptonetlab/roadmap/issues/1

• A milestone has an ETA of end of next year.
• In StarMaps it gets rendered as a small box at the end of next year
• End result is it looks like we’re not working on that milestone, unless you dig at the end of the tree and look at the leaves

[SgtPooki]

We currently aren't planning to support the manual input of date ranges for the tool, or in github issue metadata. As you said in slack, the tool should be smart enough to infer a range based on children's ETAs. However, the following items would be bugs:

• the roadmap does not render a milestone item large enough
• the milestone item does not render a correct done % based on full tree of all children n levels deep.

I think the second bullet point is the main problem that we could easily fix now to address your experience: https://github.com/pln-planning-tools/StarMaps/issues/194 let me know if you feel differently.

[anorth]

So if we want a milestone to render with a start time at date X, we need to add a child milestone with a finish date around X? Or X - 3-months (hard-coded?)?

Edit: which doesn't work today unless it's a _direct_child, but you're planning to fix it so that the time range will be set by the span of the whole descendent tree?

[SgtPooki]

Regarding the size/span of a milestone, The original decisions for this project (cc @wilkyr31d) were not to support start&end dates, and to only support ETAs. I believe that is because not everyone knows start date and only have rough ideas of end dates, it makes onboarding to the tool abrasive (UX bug). That causes the issue we see here: Milestone size does not reflect that children issues may have started before the rendered start time of a milestone item.

So we can do one of the following:

1. support start dates, but do not require them
   • Benefits:
     • when users do know their start dates for milestones, they can control the view of their roadmap better.
   • Drawbacks:
     • potential UX Bug: painful for users if adjustments are made deep in a tree and they need to go up to the parent to adjust start date
     • Different sized roadmap items will make roadmap rendering ugly. The goal of the roadmap tool is to visualize rough completion and list of tasks, not to be an exact representation of start & end dates.
2. support automatic ranges for parents based on children ETAs.
   • Benefits:
     • Removal of UX bug of needing to bounce between parents and children to ensure correct rendering
     • Removal of onboarding UX bug for teams with roadmap items that don't have clear start-dates
   • Drawbacks:
     • Child with the Earliest ETA still has the problem where start date may not be correctly reflected (I believe this is an acceptable problem)
     • we still need to render the parent with X-3*granularity or whatever to ensure "start time" is considered.
     • start time is still vague and unclear
3. A mix of the two

This decision will likely be put off until we hear from @wilkyr31d or @momack, but I think #194 will help. With #194 resolved, even if a milestone item seems not to start until 3 years down the line, it should still show correct percentage complete as children are worked on.

cc @juliaxbow

[reidlw]

Adding link to comment addressing this same thing in another issue: https://github.com/pln-planning-tools/StarMaps/issues/194#issuecomment-1329597151