tidoust
commented
1 week ago An initial thought is that we could add a floor label to each room (in addition to capacity, etc.)
That's not documented but location can already be specified in room names: Yeepee A (45 - 1st floor) would create a "Yeepee" room with capacity 45, with location "1st floor". The scheduler does not do anything with that information. The location is only used in the calendar entry. For example, the above room would appear as "Yeepee - 1st floor" in the calendar entry. Anyway, a more generic mechanism as envisioned in https://github.com/w3c/tpac-breakouts/issues/134#issuecomment-2155995592 would be preferable.
Then, in the issue, we could express a preference for a floor. If we could not fulfill the preference, we would ignore it.
That would be ideal from a code perspective. From an admin perspective, would it make more sense to specify the preference with something like "close to this and that group meeting"?
The notion of floor may not awlays be the right metric. There may be more complex layouts where rooms at the same floor are disjoint because they are in different parts of a building. Anyway, as long as rooms that are close to one another have the same location name, that should be good enough.
Some groups (e.g., accessibility groups) want to meet near one another. For TPAC 2024 I looked into fulfilling that request by assigning rooms manually to the same floor. This suggested to me that it could be interesting to enable a proximity preference. There might be multiple ways to think about this, but "by floor" seemed like a reasonable starting point.
An initial thought is that we could add a floor label to each room (in addition to capacity, etc.). Then, in the issue, we could express a preference for a floor. If we could not fulfill the preference, we would ignore it.
When looking at available rooms for a given session, rooms on the preferred floor could be tried first.