Standups: Backend Recurrence MVP Implementation Spec

[jmtaber129]

See https://github.com/ParabolInc/parabol/issues/6852 for other discussion and some alternatives considered.

High-level overview

We store state about recurring meetings/activities in a new postgres table, MeetingSeries, which contains metadata about its collection of meetings, and how these meetings recur. We introduce a new mutation, processRecurrence, which uses the recurrence information in MeetingSeries to idempotently open and close meetings accordingly. We then run this new mutation on a 5-minute interval to keep actual meeting state in-sync with what the meeting series' recurrence specifies.

Spec

Data model

MeetingSeries postgres table

• id (non null)
• meetingType - the type of the meeting. Should just be teamPrompt for now.
• title - optional title of recurrence series. Any newly created meetings should be prefixed with this title. Should just be Async Standup until we enable changing this in the UI.
• recurrenceRule - the rule that defines how this meeting series recurs. This should simply be the result of serialization from the rrule library (see "recurrence format")
• duration - the duration (in minutes)
• cancelledAt - When recurrence for this series was cancelled. Null if series is active. Can be reset to null if reactivated.

NewMeeting rethink table

New field:

• meetingSeriesId - The ID of the meeting series if this meeting is associated with one
• scheduledEndTime - when the meeting is scheduled to end

Recurrence format

We should use the RFC-2445 iCal spec, though we won't use all of its features. The rrule library supports this spec, and supports date generation and parsing+serialization.

For MVP, we should hard-code the recurrence to use the following rule when creating meeting series:

• freq - weekly
• dtstart - 9am at user's time zone or 12a EST
• byweekday - Monday, Tuesday, Wednesday, Thursday, Friday

Note that this does not include enough information to determine duration - let's assume all meetings end 24 hours after they start for the MVP, then we can add duration (including the duration column) as a follow-up.

processRecurrence mutation

This mutation does two things in the MVP:

• Close meetings that are scheduled to close
• Create new meetings that should be started based on a meeting series' recurrence rule

Closing meetings is simple - find any open meetings where now is after their scheduledEndTime, and close them.

Creating new meetings is a bit more complicated:

• For each meeting series, generate "meeting start" events after the most recent event in the series. To provide for some wiggle room, only get events after most recent meeting start + 10 minutes.
  • This should be pretty easy to do with https://github.com/jakubroztocil/rrule
• For each meeting start event in which the meeting should still be active (i.e. the would-be scheduledEndTime is after now), start the meeting, and set it's scheduledEndTime accordingly.

Important note: this mutation is idempotent - if this mutation is run twice consecutively, the second execution should have no effect. This should increase robustness, and make debugging, etc. a bit easier.

Starting/ending recurrence

(note: editing recurrence rules is out-of-scope for MVP) How recurring/non-recurring meetings are represented:

• For meetings that have never recurred, their meetingSeriesId will simply be null
• For meetings that are recurring, their meetingSeriesId should be non-null, and the meeting series should be active
• For meetings that are not recurring, but recurred at some point, their meetingSeriesId should be non-null, and point to an inactive meeting series

Setting a meeting to be recurring for the first time:

• Create a new meeting series with the relevant defaults
• Add the meeting series' ID to the meeting
• Set the meeting's scheduledEndTime to 24 hours from now (or when the recurrence rule says this meeting should end, or when the next meeting should begin)

Cancelling recurrence:

• Set the relevant meeting series' cancelled_at to now
• Set the scheduledEndTime of any open meetings to null

Restarting recurrence:

• Set the meeting's meeting series' cancelled_at to null
• Set the meeting's scheduledEndTime to 24 hours from now (or when the recurrence rule says this meeting should end, or when the next meeting should begin, or something else that makes sense)

[mattkrick]

Lookin good!

Thoughts:

• MeetingSeries might need a meetingType? I suppose we could just add it in a migration later, too.
• columns should be camel case. it's a pain to quote things in SQL, but a bigger pain when GraphQL called iscancelledAt and PG called is cancelled_at
• IMO a series should have 0 or 1 meetings open at any given time, more than 1 & you'll get users asking themselves "do i log my stuff in this meeting or that one?" processRecurrence should guarantee this.

let's assume all meetings end 24 hours after they start for the MVP

there could be dragons here, so we should explore & have a plan so the time between MVP & GA is as small as possible. Like you say, we've got a couple options:

• open the next meeting as soon as the last one closes (simple, but might be weird to have something open all weekend after the friday meeting closes)
• add a duration column to the MeetingSeries table. We could hardcode this to 24 hours for the MVP, but having that column now could save us some pain later. we can use the value here to populate scheduledEndTime
• ???

Set the scheduledEndTime of any open meetings to null Set the meeting's scheduledEndTime to 24 hours from now (or when the recurrence rule says this meeting should end, or when the next meeting should begin, or something else that makes sense)

IMO this behavior is unexpected. I'd expect a meeting series to start new meeting, but not modify existing ones. If they're already created, users should be able to let the meeting expire at its current scheduledEndTime, or they can end it manually.

Pause vs. Cancel

• what's the benefit of letting users restart series vs. just have them create a new one? for our own analytics since the same FK will get reused? if we let them restart, then they've effectively performed a "pause" vs. cancel. IMO, if they want to pause it, it should be done as an EXDATE rrule. If they want to cancel, we turn the 1-way flag cancelledAt. That way there's a distinction between pause & cancel, which we can track for analytics.

[jmtaber129]

@mattkrick

Updated the spec to address most of these, with the exception of a few:

IMO a series should have 0 or 1 meetings open at any given time, more than 1 & you'll get users asking themselves "do I log my stuff in this meeting or that one?" processRecurrence should guarantee this.

I'm not sure we want that. For example, if a team wants their standups open for e.g. 36 hours so people can add their response for the previous day, while also having today's open. I think the meeting title (which will include the date) should make it clear which meeting is which.

IMO this behavior is unexpected. I'd expect a meeting series to start new meeting, but not modify existing ones. If they're already created, users should be able to let the meeting expire at its current scheduledEndTime, or they can end it manually.

I don't think this is an accurate assessment w.r.t how this would happen in the UI. I.e. if I'm enabling recurrence from within a meeting, I'd expect the current meeting to become part of a meeting series (including being scheduled an end time), and if I'm canceling/pausing recurrence from within a meeting, I'd expect the current meeting to no longer have any recurrence artifacts (including no longer having a scheduled end time). In fact, I think it would be unexpected if I canceled recurrence for a meeting, and the meeting still ended automatically, with no way to prevent it from ending.

Re: Pause vs. cancel The main thinking is that someone may cancel recurrence for a meeting, realize they didn't want to do that, and then re-enable recurrence, which should be part of the same meeting series. Keep in mind that the concept of a "meeting series" is somewhat hidden from the user - they just see a meeting that is or isn't recurring - so forcing users to create a new meeting just to restart recurrence isn't a great experience. Additionally, I think it makes sense to keep each meeting associated with only one meeting series over its lifetime, since allowing meetings to jump from one series to another seems error-prone once we start adding more complex features (e.g. navigating to other meetings within a meeting's series).

Specifically as for pausing vs. canceling, I think this is a distinction that's outside the scope of the MVP.

[BartoszJarocki]

@jmtaber129 I'm closing this as we're likely star a new discussion when moving forward with recurrence