I'm experimenting with Phabricator for a certain widespread PHP project and it seems that the calendar would serve us well for things like upcoming dev chats, bug scrubs, release schedule, contributor days, and so forth. Most of these happen in a particular chat channel (Slack in our case), which would be very helpful to indicate separately, rather than shoving it into the title or similar. Being a separate field would allow us to do things like pipe reminders into the appropriate channels.
- Mentioned In
- T11816: Calendar: Feedback and Suggestions
T12004: Scenario: Locations Application
T11801: Calendar: ICS Import Errata
- Mentioned Here
- T2334: Implement Google Calendar v3 API into Calendar
T8022: Implement a meeting autoscheduler
T10747: Import and export ICS from Calendar
T11326: Improve Calendar v1 Design/UI/UX
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.