Add mechanism to restrict rooms for certain days

[tidoust]

In multi-day events, the list of rooms that are available may change from one day to the other. There is currently no way to say "Room X is only available on Tuesday, Thursday, Friday".

[ianbjacobs]

We might be able to achieve this with little to any new code! Suppose we create an issue with title "Unavailable" (and we update the w3c map accordingly). We hard code when the Unavailable meeting will take place and everything else is scheduled around it.

[tidoust]

There will be a little something to adjust in the code regardless of the solution ;) For example, with the "Unavailable" approach you suggest, it may be ok to let the "Unavailable" entries appear in the shedule grid, but they must not generate calendar entries.

From an authoring perspective, it seems more straightforward to me to associate the information "this room is not available on Monday" with the room itself. Also, I personally prefer if the list of issues to remain a pure list of sessions/group meetings to keep things relatively simple. For example, if I see 47 open issues today, I know there are 47 sessions/group meetings. If we add unavailable issues to the mix, the counter no longer reflects the actual number of sessions/group meetings. It's not far from it but I may need to substract one or more from the total.

Now, all metadata that we can associate with rooms currently needs to fit in the room's label (that's why we may end up with room names such as ZeRoom (28, First floor) (vip)). Adding more information about the room's unavailability in that label is going to be painful.

We crammed metadata within the label itself because, for some reason, GitHub's GraphQL API did not return the "description" that can be added to each and every field option. It turns out that the API can now return that description!

My proposal would be to move the metadata to the "description" of each room in the project's settings, using structured text such as:

- capacity: 28
- availability: Tuesday, Thursday, Friday
- location: First floor

Default value for availability would be always. And now that I think about it, vip could be repurposed as an availability value as well.

Main advantage of the description approach is that we would then have a flexible and extensible way to add metadata to rooms as needed. And that mechanism could be extended to days and slots as well if we ever need to define constraints such as "slot 1 does not exist on Tuesday", or "slot 4 ends 30mn earlier on Friday".

One possible disadvantage is that the metadata would no longer appear in the "Room" column in the project views as it only displays the field's label. The information does not seem super useful in these views, though?

[ianbjacobs]

If we go in the direction of adding an availability constraint on rooms, then it may be useful to allow the same granularity as the days and slots (where the day alone means "all the slots").

• capacity: 28
• availability: Tuesday; Thursday, 9:00-12:30; Friday

I agree we don't need the info in the views.

[ianbjacobs]

We also discussed adding "secondary capacity" (number of chairs on the perimeter) as a constraint.