Skip to content

MeetingConstraints

sasha edited this page Jan 9, 2020 · 21 revisions

Meeting constraint modelling

This page documents the constraint modelling planned for the Automatic Schedule Builder project. This is not yet final, and will probably be updated as part 1 of the project progresses.

The constraints define where and how sessions (primarily WGs and BoFs) in meetings should be planned. Different constraints may different priorities, as a conflict-free schedule may not always be possible.

Business logic constraints

The following constraints are planned to be part of the business logic of the scheduler, although they will use information from the database, e.g. to determine which sessions are a BoF.

Constraint Comment
A single room during a single time slot can only have a single session Absolute requirement
BoFs cannot conflict with any other BoFs
BoFs cannot conflict with any other WGs in their area
BoFs cannot conflict with PRGs
BoFs cannot conflict with any area-wide meetings (of any area)
Area meetings cannot conflict with anything else in their area
Area meetings cannot conflict with other area meetings
WGs overseen by the same Area Director should not conflict Some ADs also oversee WGs outside of their main area

The area meetings are: dispatch, gendispatch, intarea, opsarea/opsawg, rtgarea, rtgwg, saag, secdispatch, tsvarea, irtfopen. Many of these have type "area" in the database, but not all. The database will likely have to be extended to record all area meetings. Except for this, all data is already available in the datatracker database.

Per-session constraints

Per-session constraints are entered by users when requesting their session.

All but the first are currently communicated through free-text comments. The possibility of free-text comments will remain, but their usage should be very limited with the support for the constraints listed below.

Constraint Comment
Conflict with other WG, BOF or whole area Chair conflict highest priority, technology overlap second, key person third
Timeslot preference WGs may declare mornings/afternoons of each day as "not possible" or "preferred"
Timing between multiple sessions of same WG WGs may declare they want their sessions on consecutive days, or with at least one day in between
Adjacent session with other WG WGs may declare they want their session to be scheduled immediately before/after another WG, same room, no break
Joint meetings Multiple WGs hosting one session together.

Joint meetings are the most complex case, and require further research on the current data model to work out exactly how to implement them. The end result should be that for a joint session, the conflicts from each WG that is part of the session should be considered. So for a joint session between dnssd and homenet, chair conflicts, technology overlaps and key persons, should be included for both WGs.# Attachments

Clone this wiki locally