-
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 create_dummy_meeting management command can be helpful for the development of the automatic schedule builder. It creates an IETF 999 meeting based on IETF 106, but with almost all comments translated to proper database constraints. It can be run with the --delete option to delete the dummy meeting. (The attached script-generator.py script was used to generate the initial version.)
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 | Weight |
|---|---|---|
| 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 |
An area meeting is any session of any group that has type set to ag, type set to area, or the meeting_seen_as_area flag set.
Per-session constraints are entered by users when requesting their session.
All but the first two have previously been communicated through free-text comments. The possibility of free-text comments will remain, but their usage should be more limited with the support for the constraints listed below.
| Constraint | Name in DB | Comment |
|---|---|---|
| Conflict with other WG, BOF or whole area | conflict, conflic2, conflic3 | Chair conflict highest priority, technology overlap second, key person third |
| Key person | bethere | |
| Timeslot preference | timerange | WGs may declare mornings and early or late afternoons of each day as "not possible" |
| Timing between multiple sessions of same WG | time_relation | WGs may declare they want their sessions on consecutive days, or with at least one day in between |
| Adjacent session with other WG | wg_adjacent | 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. | Not applicable |
Joint sessions are the most complex case. A session is joint when multiple WGs have one session together, in the same timeslot in the same room. For automatic scheduling, a single Session object in the database should correspond to a single session to be scheduled. There are two types of joint sessions.
Type A applies when two WGs decide to have one joint session. They do not have any individual sessions. For type A:
- One WG must make the request, listing the constraints of the entire session in their request.
- In the one request, the other WG should be entered as "joint with".
- For the scheduler, no special constraint logic applies: this appears as a single session with a single set of constraints.
Example: the request made by opsawg in IETF 105 and 106: PLEASE NOTE: Combined OpsAWG / OpsAREA (no separate request made for opsarea)
Type B applies when a WG decides to have one session joint with other WGs. The other WGs have sessions of their own. The WG organising the joint session may or may not have their own sessions. For type B:
- The WG organising the joint session makes the request, listing their own constraints in the request.
- In this request, the other WGs should be entered as "joint with", and the requester should specify which of their sessions (if multiple) is a joint session.
- For the scheduler, for the joint session only, all constraints of the request, plus all constraints of all joint WGs (entered in their own requests for their regular sessions) should be considered.
Example: the request made by idr in IETF 106: Please note the 3rd session is for a joint session with security people handling IPSEC tunnels (I2NSF, IPSECME), IDR and BESS. (idr has other sessions too; i2nsf, ipsecme and bess all have a session of their own as well)
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