@johnstcn @tjcran Looks like we need to sort out what remaining work we have that needs to be added to the Community MVP for this epic.

@johnstcn @tjcran Looks like we need to sort out what remaining work we have that needs to be added to the Community MVP for this epic.

I will leave this for @johnstcn or @vapurrmaid. There are not additional product requirements to add to this, only issues needed for implementation decomposition.

My understanding was that using the schedule based auto-off system, it would basically schedule a stop time 8 hours in the future.

Please add your planning poker estimate with ZenHub @johnstcn

Discussed with @vapurrmaid and this is probably the simplest approach that also evolves with the user's habits.

One could argue as well that it also make sense to default the autostart time to now.

I think this could be better handled by the approach in #1433, since it solves the problem of a default as well as the problem of control.

Also, we want to avoid site-wide settings as much as possible.

• We have large customers, and seldom will a 500 person deployment want an across the board workspace scheduling policy.
• We want to deliver a multi-tenant SaaS, potentially even within the next 12 mos

@johnstcn we should breakout discuss this in tandem with #1433 early next week so we can have those two groomed and broken out/decomposed technically.

The product intention is that we want to introduce ways to control automated workspace lifecycle behavior for the reason of cost control and resource optimization.