I expect to do this eventually, but I'm hesitant to just put a freeform "Location" text field on events. If we do, we can't prevent double-booking physical meeting rooms, since users may spell physical space names differently and we can't know for sure that "Meeting 6", "Meeting Room 6", "Meting Rum Six", and "Meeting Room#6" are all the same.

If we build locations as a real object instead and know that "Meeting Room 6" is a physical room, we can prevent/warn about double booking. We can also help users find unused meeting rooms at a particular time.

This isn't as useful for purely virtual spaces like chat channels, although it might still be useful to avoid double-booking #general or whatever. Even if there isn't a double-booking issue, formalizing this would let you quickly see everything scheduled in a particular channel or other virtual space.

If we're building a list of "Location" objects, it's probably worthwhile to try to accommodate some other use cases. Two that spring to mind are:

• building/facilities maps; and
• employee desk locations.

Facebook had some internal tools for answering questions like these:

• I have a meeting in "Meeting Room 6" in that other new building, how do I find the actual room?
• Where is Chad's desk?

Also not too relevant for virtual spaces, but potentially pretty useful for physical ones. If we're trying to tackle these problems too, locations probably need to be hierarchical so you can find a room by building, we can show you rooms in your building by default, etc.

Even with purely virtual spaces, it might be nice to group "Slack Channels" together if you have other virtual spaces in the future, or begin booking some physical events as well.

I think the pathway forward here is a new "Locations" application which looks something like this:

• Hierarchical locations, so you can lay out California → Palo Alto → Building 151 → Meeting Room 6 or Slack Channels → #general, and users can do things like find a free meeting room in a particular building.
• Locations have flags to determine if they can be booked for a meeting, if only one simultaneous booking is allowed, who can book them, etc.
• Eventually, support for building maps to help you figure out where meeting rooms are.
• Eventually, support for desk locations.
• As you walk around campuses using your phone, a corresponding avatar appears on the building maps and can catch nearby Pokemon.
  • I think we could actually build this without writing a whole app? We can query your location in the browser now, and you could specify coordinates for maps...

Calendar is currently prioritized, but the scope is focused on basic functionality (getting it out of the "prototype" stage, roughly described in T11326 with more recent activity in T11326) and API integrations (Google Calendar in T2334, ICS in T10747).

Locations (here) and autoscheduling (T8022) are probably further out. There's some scope flexibility in what happens with Calendar, but I'd expect this first iteration to complete and stabilize before we look toward either of these improvements.

IMO, Pokémon catching is an essential feature, please implement that first.