Page MenuHomePhabricator

Implement a meeting autoscheduler
Open, NormalPublic

Assigned To
Authored By
May 1 2015, 3:25 PM
Referenced Files
F649128: wiggio-1.png
Jul 23 2015, 12:01 AM
F649129: wiggio-2.png
Jul 23 2015, 12:01 AM
F649136: wiggio-3.png
Jul 23 2015, 12:01 AM
"Like" token, awarded by CodeMouse92.


Problem: Scheduling serious business meetings often requires multiple rounds of back-and-forth. In the degenerate case, everyone describes a vague version of their availability first (like "oh, I'm mostly free later this week") because specifying their exact availability would be tedious, then once enough people have kind of implied their availability someone suggests some times, then some people confirm, then some other people say they can't do that time, can we do a different time? then a different suggestion is selected, then no one really objects so that's when the meeting likely happens. This is pointless and time consuming.

Proposed Solution: For business meetings which fit this pattern (vs parties, external events, etc., which must happen at a specific time), attendees only tell Calendar about constraints. It automatically schedules meetings which satisfy these constraints.

Walkthrough: As a host, this might look something like:

  • You go to Calendar and choose Create EventSchedule Meeting... or similar.
  • This puts you into a modal create workflow which gives you constraint controls instead of start time + end time controls.
  • Broadly, you specify the meeting duration and a range of acceptable dates and times, using some reasonable interface. For example, you might be scheduling a lunch meeting and acceptable times are 11AM - 2PM on this Thu, Fri or next Mon.
  • You fill in the rest of the details and hit "Create Event".

You arrive on the event detail screen, where everything looks normal, except:

  • Calendar has chosen a start time from the available times.
  • The start time is marked "(Tentative)".
  • The event as a whole probably has a "(Tenative)" label, although maybe this isn't necessary.

As an attendee, the workflow looks like this:

  • You get a normal email about the event.
  • It marks the start time as tentative.
  • It has additional instructions: "If this time doesn't work for you, specify your availability when RSVP'ing to the event."
  • You RSVP. When you click "Attending", you get a scheduling dialog instead of a confirm dialog. This dialog uses similar "constraint controls" to those above.
  • In the scheduling dialog, you specify additional constraints ("I can't make it on Thursday") using these controls.
  • If there is a better time for the meeting to take place given the new constraint information, the meeting is immediately rescheduled.


  • When the last attendee RSVPs, the meeting is no longer "Tentative".

Considerations: Overall, the system should have these properties:

  • Events should always have a time, even if that time is marked "tentative". If we wait for everyone to RSVP before scheduling the meeting, one person not RSVP'ing prevents the meeting from happening. This is bad/undesirable. The tool should generally be pushing meetings toward happening and happening with less involvement, not more.
  • When selecting constraints, we should fill in all of the events we know you're attending by default.
  • Users can always adjust constraints later, if their schedule changes.
  • Your preferences should count more if you RSVP than if we passively read your status out of your calendar (to encourage users to RSVP, and improve the accuracy of constraints).
  • In cases where two alternative times are about equally attractive, your preferences should count more if you RSVP earlier than if you RSVP later (to encourage users to RSVP promptly).
  • We should leave probably blocks between meetings by default. (Eventually, we can add formal locations and have more information about how long it will take people to travel between meetings.)
  • While we don't want to reschedule meetings idly, I think we should start by being fairly liberal about rescheduling in order to get a better time and then make them less fluid in response to feedback if necessary. For instance, it might be bad to move 10 AM meeting if it's currently 20 minutes before the meeting. But we can be gradual about this in various cases where this is important: fluid reschedule by default -> no reschedule by default -> require a confirmation -> require a confirmation plus a note apologizing for being a jerk -> require an explicit rescheduling edit by the host. We might also want to let the event owner easily "lock" a meeting to a specific time (basically, remove the "fluid" magic).

Constraint Cascading: This will introduce a hard computer-sciency problem where you try to RSVP to a fluid meeting and you're busy at all of the available times, but some of your conflicts are other fluid meetings which could be moved. If we were really smart, we could automatically move those meetings around and find an optimal schedule across your whole set of fluid meetings. We should just ignore this for now because it's almost certainly extremely hard. If the feature is good/useful overall, we can consider being smart about it later.

Event Timeline

epriestley assigned this task to lpriestley.
epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added a project: Calendar.
epriestley added subscribers: epriestley, chad, btrahan.

From a technical point of view, I think this looks like:

  • Since meetings always still have a start time, nothing changes there.
  • The duration of the meeting can be stored implicitly by comparing the start and end times. When the meeting is rescheduled, we keep it the same length.
  • Events get a new isFluid flag or similar. This flag means that the meeting should use constraint-based scheduling.
    • When users select Create EventSchedule Meeting or similar, instead of Create EventNew Private Event, this flag is set.
    • Hosts can probably add or remove this flag later if they want, but we don't need to worry about this for now.
  • Events get a new isTentative flag or similar. This flag is primarily just a hint to humans that the meeting may reschedule.
    • This flag is set when a new isFluid event is created.
    • This flag is cleared when the last user RSVPs.
    • If we let hosts remove isFluid, doing so also removes isTentative.
    • This flag might automatically go away when the meeting gets close to happening
    • When this flag is set, we should show more hinting in the UI about tentativeness. Email and workflows should be more fluid (for example, default to freely rescheduling).
    • When this flag is clear, we should show less hinting, and the workflows should be firmer. For example, default to not rescheduling.
    • Broadly, this is just trying to make fluid meetings feel fluid, but let them transition to feeling concrete before they happen so people have time to prepare.
  • We need to store invitee constraints. I think these need to be per-event: invitees may have preferences for a specific event (like when they want to eat) which aren't really global constraints.
    • This might make the most sense to just store as a big blob on the event itself?
    • This probably looks like a map from each user to times which do and do not work. These settings override the settings implied by other events on their calendar.

We also need to figure out what the constraint UI looks like. The easiest/dumbest thing I can come up with is like a huge table of checkboxes, but we can probably do better than that by writing LOTS OF JAVASCRIPT HOORAY.

Maybe an even easier/dumber solution is a DSL where you just type stuff in a box? I think this is probably too hard to use for most users:

mon-wed 11-2
fri 10
not thursday
not 1PM

It might be worth mentioning that has this exact feature. For them, the person doing the scheduling specifies the days and times that the meeting could start on, and then everyone checks the boxes for the timeslots that they are available. Like you mentioned, not the most innovative UI, but it is very effective.

wiggio-1.png (391×1 px, 30 KB)

wiggio-2.png (373×599 px, 36 KB)

wiggio-3.png (511×594 px, 50 KB)