Unique ID for events and slots

[meatballs]

Currently, the scheduler uses the index of an event or slot in the relevant list as the event/slot id.

However, this causes problems over time as the events and slots lists change (e.g. new events are added, rooms become unavailable) and the position of a given event or slot within the lists changes.

Instead, we should accept id codes for both and assign them if missing. For events, this could be a UUID4 code. For slots, a hash of the room, start time and duration.

[drvinceknight]

After our chat today, I took another look and reminded myself about the issue and the manual step we had to use in 2017.

I'd suggest you change this at the https://github.com/PyconUK/ConferenceScheduler-cli level and having those ids and hashes as you describe would be a great way to do that there 👍.

(Just my two cents :) 👍)

[meatballs]

I think most of the work needs to happen at the cli level (or whatever other wrapper we might use) but we also need to add a uuid attribute to both the Event and Slot classes in resources.py

[meatballs]

Another thought struck me: This affects the consistency optimisation, so it needs to be addressed here.

[meatballs]

IIRC, the manual step we used in 2017 was to fix the order of the events when we extracted them from the db - but that still caused problems when events were cancelled and didn't appear in the extraction at all.

[drvinceknight]

Another thought struck me: This affects the consistency optimisation, so it needs to be addressed here.

The approach I'd suggest would be to always ensure a consistent order of events is passed to the solver. This was the manual step we undertook in 2017: needing to copy and past two cells in a spreadsheet if I recall (because the cli created a column for the talk and another for the index or something like that) - so in essence my suggestion would be to make that "double" copying and pasting automatic outside of the scheduler.

but that still caused problems when events were cancelled and didn't appear in the extraction at all.

From the point of view of the scheduler cancelled events can be "left in" and just omitted from the schedule output outside of the scheduler. EDIT Or better just remove the cancelled event from the schedule that's passed "back to" the scheduler (which corresponds to removing a given row from the matrix representation of the schedule).

However, my thoughts are very much from the point of view of isolating the scheduler and the LP to "just" optimise a list of events and slots and I'm sure your suggested approach is a completely valid way to solve the problems 👍

[meatballs]

The approach I'd suggest would be to always ensure a consistent order of events is passed to the solver.

This has proven more difficult to achieve than we thought - e.g. changes of talk title mean we can't use it in the sort order

From the point of view of the scheduler cancelled events can be "left in" and just omitted from the schedule output outside of the scheduler.

I don't understand the suggestion here. If the cancelled events are left in, how do we handle the constraint that every event must be scheduled? If we schedule them, we run the risk of using any slack on cancelled events or running out of slots altogether.

... of isolating the scheduler and the LP to "just" optimise a list of events and slots

Yep. That's very much what I want too! I just feel that this is one example where we have to 'pollute' it with info from the outside world a little.

[meatballs]

Or better just remove the cancelled event from the schedule that's passed "back to" the scheduler

I'm starting to think this might be the way to go.

[drvinceknight]

FWIW, my suggestion would be the following workflow:

Have a database of some sort with events and slots (outside of the scheduler, I'm guessing an sql database?).

A script that reads that database and creates slots and events. Note that this script would handle change of title, etc (these things don't need to be in the scheduler events - a hash or whatever would do)... So instead of scheduler.Event("How to run a lightning talk session", ...) we would have scheduler.Event("qheu49", ...) and the script just knows that qheu49 points at the talk "How to run a lightning talk session".

The scheduler schedules those slots and events.

Another script that takes the slots and events and displays them in a user friendly way (csv file) and likewise takes a user friendly schedule and translates it to a matrix (or likewise).

Now:

• If we modify things manually on the user friendly way and want to validate: script reads in from database and the csv file and recreates the slots and events (order doesn't matter). The scheduler can validate.

• If we want to change the schedule (minimising distance from another schedule). Create slots, events (this will be newly updated from the database) and current schedule (from csv file). If events are added and/or slots removed this just gets incorporated in the "current schedule". The scheduler can reschedule.

I would not add any outside information as it's not really necessary to the scheduler. Fundamentally I believe we are talking about the same thing, a layer that keeps track of what events are what. The scheduler itself will always just want a list of events and slots so I'd suggest that that layer is outside (as it's just something to keep track of things - it doesn't need much).

But that's my two cents :) As I wasn't involved last year perhaps I'm missing something 👍