Align with domain model

[tijlleenders]

Is your feature request related to a problem? Please describe. Docs need to be updated with new terms.

Describe the solution you'd like Code in #431 resolves the confusion about the domain model, in my opinion:

• The Calendar has Hours - which have status Free or Occupied.
• Goals can be of type Budget Goal or Simple Goal (or later Simple Filler Goal - or Budget Filler Goal)
• Both types of Goals get translated into Activities to be placed on the Calendar
• Each Activity has an internal overlay_calendar where static constraints are respected - and where each Hour points to the corresponding Calendar Hour - so it can know how many other activities want that Hour - or if it has been 'taken' by some other Activity.
• Calendar Hours that have been 'occupied' by an Activity are considered Tasks.
• Tasks can be 1h or multiple hours.

This still needs to be integrated into the docs - so leaving this open.

Describe alternatives you've considered

Additional context This was previously a slightly different issue - but updated the issue text to reflect new insights into the domain language that 'works'.

[tijlleenders]

@thinkrapido @kobe-reygel

429 mentions 'TimeSpan'. This seems like a new concept - not yet present in the code.

Is this new or a replacement for what you called 'Day' before?

Obviously, the ZinZen scheduler concepts are not intuitive, as each time a new person comes onboard we try to introduce new names for things that more or less already exist... We should solve this semantic ambiguity before moving on.

Inspired by #429 - and assuming this is the same concept as 'Day' and the legacy 'Timeline' - I've come up with yet another name proposal (yes, naming is hard).
Let's rename Day/Timeline/TimeSpan to TimeSpaces.

• Day is far from perfect, but a great initial move for the simplest test case. This needs to evolve so we can discard the artificial midnight boundaries the scheduler doesn't care about.
• Timeline was the legacy name, but also doesn't fit as it suggests a linear, uninterrupted span of time.
• The argument against TimeSpan is similar to that of timeline. The definition of Span is that it encompasses the entirety of the space between the extremities, which doesn't allow for filtering. It could be acceptable if we make it plural, so TimeSpans
• This brings me to the TimeSpaces proposal. I believe 'space' is a more neutral way of framing than 'Span' - suggesting the possibility - but not the necessity of occupying the area. You find a 'place' in the larger 'space'. You 'place' a Task within the TimeSpaces. You find a Spot/Slot/Niche within the possible space.
• I also like @thinkrapido 's introduction of (un)occupied 'Seats' - maybe TimeSeats as another option???

For the second part of this issue (renaming min_span to min_duration) I think @thinkrapido are already in agreement after the Budget discussion. Budgets and Goals extend the base Activity. For Goals, there is a total_duration and a remaining_duration - as wel as a min_block_size (min_span_size?) and max_block_size.

Curious to hear your thoughts!

[tijlleenders]

Another idea is to let the Calendar own the Seats/Hours/... (whatever the unit of measure of the Calendar is) - with status Free or Occupied for each unit - and each Activity having a CompatibleSeats collection with references to the Seats/Hours of the Calendar that fit the ActivityConstraints.

Each Activity will know its own Flexibility - that automatically excludes anything that doesn't fit the ActivityConstraints, as well as any reference to a unit that has status Occupied. The scheduler can request the Flexibility from each Activity to determine which Activity gets scheduled next.

During assignment of Seats/Hours to the Activity that gets selected by the scheduler, the scheduler can ask the Calendar for the number of Claims by other Activities for each (set of) Seat(s)/Hour(s) the Activity proposes as a suitable option. The claims are known using the Rc count of the Calendar Seat/Hour, making it easy for the scheduler to see which of the proposed (set of) Seat(s)/Hour(s) has the least conflicts with claims from other Activities.

Weak and strong Rcs could be used to auto-break the reference upon actual allocation/scheduling - or differentiate between scheduled/unscheduled status?

[tijlleenders]

@thinkrapido @kobe-reygel @Tushar-4781 I think I figured out how Rc works ... and how we can use it to keep track of hour-claims.

Here's a 300 LOC proof of concept with the scheduler-challenge testcase working. main.zip

I was a little lazy on the flex and scheduling loops; they just iterate over the whole calendar from start to finish...
I suspect this will not have any noticeable performance impact - but it does keep the loop simple to understand.

[tijlleenders]

@thinkrapido @kobe-reygel

Code in #431 resolves the confusion about the domain model, in my opinion:

• The Calendar has Hours - which have status Free or Occupied.
• Goals can be of type Budget Goal or Simple Goal (or later Simple Filler Goal - or Budget Filler Goal)
• Both types of Goals get translated into Activities to be placed on the Calendar
• Each Activity has an internal overlay_calendar where static constraints are respected - and where each Hour points to the corresponding Calendar Hour - so it can know how many other activities want that Hour - or if it has been 'taken' by some other Activity.
• Calendar Hours that have been 'occupied' by an Activity are considered Tasks.
• Tasks can be 1h or multiple hours.

This still needs to be integrated into the docs - so leaving this open.