-
Notifications
You must be signed in to change notification settings - Fork 395
MeetingConstraints
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.
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 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.
Currently processed manually:
- As long as the total amount of time stays the same, unless the groups have expressed a preference otherwise, their session lengths are often swapped. For example, if a group requests two 1.5-hour sessions, they may end up with one 2-hour session and one 1-hour session if that fits in the grid better.
- If a group requests two sessions, it’s more likely that one of them will be on Friday (Friday is generally the least popular day).# Attachments