Add Remaining built-in constraints

[pyconuk]

Add Remaining built-in constraints

[drvinceknight]

duration - only scheduling events in slots with a matching duration

I'll pick this up next.

suitability - not scheduling events in rooms which are unsuitable for that type of event

I think this is covered: we can mark an event as unavailable for a given slot. We can pre process whether or not a given event is suitable for a given slot when we get the data in (and just add that to the event unavailability).

[drvinceknight]

duration - only scheduling events in slots with a matching duration

Actually, come to think of it: that's also already covered by the same logic: we can simply include this all in a data input validation:

• If an event has duration 30 mins then all the slots with duration < 30 mins should be marked as an unavailability for that event.
• If an event has a particular type then all the slots that cannot cater for that type should be marked as an unavailability for that event.

[drvinceknight]

I'll pick this up. Will start with the tags constraint: so talks cannot be scheduled in the same session unless they share a tag.

[meatballs]

including no tag? i.e. Any untagged talks can be scheduled in the same session.

[drvinceknight]

Yup. I'm thinking we can handle that generically: no tag is a tag.

[drvinceknight]

@meatballs currently the unavailability maps speakers to slots. Would you be averse to changing that to map from events to slots?

So this would have:

 21 class Event(NamedTuple):                                                                                                                          
 22     name: str                                                                                                                                     
 23     event_type: EventType                                                                                                                         
 24     duration: int                                                                                                                                 
 25     roles: Dict[Role, Person]                                                                                                                     
 26     tags: List[str]  
 27     unavailability: List[Slot] 

The unavailability list for any given event would by default be empty.

This would just make things a little bit more generic and also addresses our chat that unavailability for an event in a given slot need not be about the speaker (as a committee we could decide that we don't want a particular event to happen in a particular room).

[meatballs]

we don't want a particular event to happen in a particular room

I think that's a separate issue

The main issue to deal with for unavailability is that we will straight away have speakers telling us that they cannot be at the conference for particular days. That's what I mean by 'unavailability.'

[meatballs]

So, I don't see how it could be mapped to an Event - anyone who can't make Friday still won't be able to make Friday regardless of what we've scheduled that day.

[drvinceknight]

This is just about how the data is stored and doesn't actually change anything.

The main issue to deal with for unavailability is that we will straight away have speakers telling us that they cannot be at the conference for particular days. That's what I mean by 'unavailability.'

When speakers say they are unavailable for a given day that in effect translates to the events that "belong" to that speaker being unavailable on the slots on a given day. So this doesn't change anything from that point of view.

By allowing for events to be more generically unavailable on a given slot it just makes things a bit more flexible.

This branch has those changes and the availability constraint programmed in: https://github.com/drvinceknight/ConferenceScheduler/tree/2-availability

(It's forked off my work on #5, will wait for that to go in before opening the PR)

[meatballs]

When speakers say they are unavailable for a given day that in effect translates to the events that "belong" to that speaker being unavailable on the slots on a given day.

It also translates to sessions that they might chair, speakers they might be mentoring, workshops they might be assisting at and other things we haven't even thought of.

[drvinceknight]

True and similarly we can have events that the committee doesn't want to schedule in a given slot even if the speaker is available (for some reason). Perhaps we need unavailability in both authors and events... I'm at an all day thing, I'll open the PR when I get a chance and we can discuss there? :)

…

On Tue, 2 May 2017, 09:03 Owen Campbell, ***@***.***> wrote: When speakers say they are unavailable for a given day that in effect translates to the events that "belong" to that speaker being unavailable on the slots on a given day. It also translates to sessions that they might chair, speakers they might be mentoring, workshops they might be assisting at and other things we haven't even thought of. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACCGWj9sLG9sEsVkiBhX1XjUt1hW4pAPks5r1uNngaJpZM4NNLmj> .

[meatballs]

True and similarly we can have events that the committee doesn't want to
schedule in a given slot even if the speaker is available

But that's a different issue - one that I think should be covered by an ad-hoc constraint in the 'script' for that year. Here, we're just trying to deal with the built-in availability constraints.

[drvinceknight]

Cool. I'll tweak, push and PR when I get a moment (might be later today).

…

On Tue, 2 May 2017, 09:14 Owen Campbell, ***@***.***> wrote: True and similarly we can have events that the committee doesn't want to schedule in a given slot even if the speaker is available But that's a different issue - one that I think should be covered by an ad-hoc constraint in the 'script' for that year. Here, we're just trying to deal with the built-in availability constraints. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACCGWojXvdoobK0rBITT3Zkl6VHWD6adks5r1uXIgaJpZM4NNLmj> .