Migrate Services

Note

The following message was originally posted by @BekahHW in the New Events Calendar Service discussion:

I want to add another layer to this conversation as we think about moving off CraftCMS + Airtable. Right now, we maintain community info in multiple places: the CMS, Airtable, VC-Community-Docs, and virtualcoffee.io. That means when a host changes or a group takes a break, someone has to remember to update at least two or three different spots. It’s easy for things to fall out of sync. (Shoutout to @meg-gutshall who frequently feels this pain point)

I think we may be able to solve both problems together. Instead of replacing the CMS/Airtable with another silo, we could create one source of truth for groups + events (YAML files in GitHub, or a small Postgres/SQLite DB). From there:

• Next.js site pulls that data to render the live directory + calendar.
• Docs site (Docusaurus) shows a snapshot and links back, so “process” and “practice” stay cleanly separated.
• Slack automation posts reminders and Zoom links straight from the same data.
• ICS feeds can be generated automatically, so members can subscribe in Google/Apple/Outlook.

This way we’d:

• Eliminate CMS costs.
• Avoid maintaining info in multiple places.
• Make it easier for contributors (one PR or DB update = everywhere updated).

Even if we start repo-first (YAML + GitHub Actions) and grow into DB-backed later, it gets us away from both vendor costs and update fatigue.

Single source of truth detailed proposal (cost-cut + fewer updates)

Keep a single data source (YAML in GitHub or a tiny Postgres/SQLite) that defines:

• Groups (stable): id, name, Slack channel, hosts, status, description
• Event rules (dynamic): title, timezone, RRULE for repeats, plus overrides and one-offs

From that one source, auto-generate:

• Next.js directory + events pages
• Docusaurus snapshot on process pages (link back to the live directory)
• Slack reminders with Zoom buttons (cron)
• ICS feeds (per type + master)

Libraries:

• rrule (ICal RRULE in JS/TS): defines weekly/biweekly/monthly repeats and gives us the dates to expand.
• luxon (or the native Temporal polyfill): safe timezone + DST handling.
• ics (or ical-generator): build downloadable ICS feeds members can subscribe to.
• date-fns-tz (optional): lightweight time formatting by zone.
• @slack/web-api: post daily reminders with a “Join Zoom” button pulled from the same data.

Essentially, this is the solution I'm trying to champion:

Data-wise, it would look something like this:

# coffee-table-groups.yml
- id: accountabilibuddies
  name: Accountabilibuddies Group
  slackChannel: announcements
  hosts: [{ name: "Meg Gutshall", handle: "@meg" }]
  status: active

# events/recurring.yml
- id: tues-coffee
  groupId: tues-coffee
  title: "Virtual Coffee Tuesday Coffee"
  timezone: America/New_York
  startLocalTime: "09:00"
  endLocalTime:   "10:00"
  rrule: "FREQ=WEEKLY;BYDAY=TU"   # <— RRULE defines the repeat
  location: { type: zoom, url: "https://zoom.us/j/XXXX" }
  visibility: public
  overrides:
    - date: "2025-11-26"   # cancel pre-holiday
      action: cancel
    - date: "2025-10-31"   # time/title tweak
      action: modify
      title: "Halloween — Wear your Halloween Costume"
      startLocalTime: "09:00"
      endLocalTime: "10:00"

- id: algos-pop-up-jan15
  groupId: algorithms-reading
  title: "Algos Pop-up: Divide & Conquer"
  timezone: America/New_York
  oneOff:
    date: "2026-01-15"
    startLocalTime: "17:00"
    endLocalTime:   "18:00"
  location: { type: zoom, url: "https://zoom.us/j/YYYY" }
  visibility: public

[meg-gutshall]

Here's the associated project for this: https://github.com/orgs/Virtual-Coffee/projects/29

[meg-gutshall]

EMERGENCY PLAN

@JoeKarow and I paired in the #co-working-room earlier this afternoon. Since I’m going to cover Zoom costs going forward and Dan is covering the CMS costs for the time being, we’re going to prioritize backing up all the data on Airtable and recreating its functions.

IMMEDIATE PRIORITIES

FUNDRAISE!! We still have monthly costs -- on top of the deficit that has built up. We need to figure out how to make it up!

1. We’re looking into Neon (via Netlify) and Cloudflare as possible free tier databases. Once we decide on one, we’re going to move the data from Airtable into the database.
2. Joe will recreate the #co-working-room workflow using the Slack API. There’s already been a lot of discussion around this and he has a proof of concept to go off of.
3. I am going to recreate the waitlist to member workflow using our Google workspace. I’ll make the waitlist using Google Forms and automate the emails sent from the hello address.
4. After that, I’ll recreate the CoC violation and Lunch & Learn submission forms.
5. Next, I’ll move the events to the Google calendar while Joe works on redesigning the events page. We’re going to include the option to subscribe to each type of event as its own RSS feed since Google supports that out of the box.

I think that covers the bare basics of keeping things running for now. Please let me know if I missed anything major!

SECONDARY PRIORITIES

1. Build a replacement CMS based on free, open-source software. Once this is complete, we'll move the waitlist to member workflow and all of our other forms there. We can possibly tie in our "single source of truth" solution here.
2. Assess the feasibility of moving off of Zoom. Is there another platform that can support our needs for less money? Can Discord work if we use Google Meet for the Tuesday/Thursday meetings, or will it be the death of VC?

References

• Use the Slack Calls API for #co-working-room discussion
• Slack's Using the Calls API documentation
• Zoom meeting webhook documentation
• Eddie's prototype
• Eddie's PR

[justinnoel]

Build a replacement CMS based on free, open-source software

Cloudflare now has EmDash CMS based on Astro and their D1 sqlite database.

https://blog.cloudflare.com/emdash-wordpress/

I can help with setting evaluating this, testing, and setup if y'all want to consider it.

[justinnoel]

Assess the feasibility of moving off of Zoom.

I don't have any idea of our costs. Perhaps we could try Whereby? I'm not sure if it would be cheaper or not.

I've used it in the past. It's not as complete a solution as Zoom, but if it is significantly cheaper, it may be worthwhile.

https://whereby.com/information/meetings/pricing

[justinnoel]

Assess the feasibility of moving off of Zoom.

We could consider rolling our own video software using the daily.co pre-built tooling. Basically, we'd create an app or a website that has that built in.

I've dabbled with their platform many years in the past. It wasn't particularly hard to get something basic up and running.

I made some rough guesses of the amount of video meetings we have. Here's the link to it. Feel free to play with the numbers.

https://sheet.zohopublic.com/sheet/published/7j5916f7eb313c09a487b92fefe567afb52c0

[justinnoel]

Cloudflare D1 could be a bare bones Airtable implementation.

Alternatively, we could host NocoDB on PikaPods for $2.30/mo.

[meg-gutshall]

Assess the feasibility of moving off of Zoom.

We could consider rolling our own video software using the daily.co pre-built tooling. Basically, we'd create an app or a website that has that built in.

I've dabbled with their platform many years in the past. It wasn't particularly hard to get something basic up and running.

I made some rough guesses of the amount of video meetings we have. Here's the link to it. Feel free to play with the numbers.

https://sheet.zohopublic.com/sheet/published/7j5916f7eb313c09a487b92fefe567afb52c0

Thanks, Justin! I glanced over the site a bit and find it to be an interesting alternative. I'll pull reports from the past few months on Zoom so we can get a more accurate estimate of what the costs would look like.

[meg-gutshall]

As far as task 3 goes on the above list, I've decided to use AI to help with this. Here's the prompt I'm going from and I'll refine it along the way. In the meantime, does anyone have feedback for me?

I have an Airtable app that I want to recreate in my Google Workspace and I need help. It allows people to sign up 
on a wait list to join an online group called Virtual Coffee and helps the maintainers of the group by automating 
the acceptance process. It contains Data, Automations, and Interfaces and connects to third-party tools including 
Slack and Zoom.

The high-level flow is as follows:

1. A user submits our "Join the Virtual Coffee Waitlist" form, hosted at virtualcoffee.io/join and connected to the 
Airtable app.
    a. A new entry is created in the membership table and populated with the user's submitted info plus timestamps, 
    IDs, and other various attributes. This is akin to an entry in a database.
    b. A notification is then sent to a private Slack channel to alert the maintainers of a new waitlist submission. 
    The maintainers periodically remove people from the waitlist depending on how much volunteer support is available.
    c. A notification email is then sent to the user, informing them of their successful addition to the waitlist 
    and next steps. It is sent from our hello@virtualcoffee.io email address.
2. The maintainers visit the "Approve from waitlist" Interface, which lists the users currently signed up for the 
waitlist. When a user is selected, more detail renders, showing the completed form and an "Activate" button.
    a. On click, the user moves from the "Approve from waitlist" Interface to the "Approve pending member" Interface 
    and the user's new status is updated and timestamped in the corresponding entry in the membership table.
    b. A notification email is then sent to the user, informing them of their removal from the waitlist and inviting 
    them to attend a Virtual Coffee meeting at their earliest convenience. This email contains Zoom links to our 
    weekly meetings and details on what to expect. It is also sent from our hello@virtualcoffee.io email address.
3. Once the user attends their first Zoom meeting, the maintainer returns to the "Approve pending member" Interface. 
This Interface is designed much like the "Approve from waitlist" Interface except the button is labeled "Approve."
    a. On click, the user is removed from the "Approve pending member" Interface and the user's new status is 
    updated and timestamped in the corresponding entry in the membership table.
    b. The user is invited to join the virtual-coffee-group.slack.com Slack workspace.
    c. A welcome email is sent to the user with onboarding information about the Virtual Coffee community.

I'd like to recreate the above workflow, reserving the option to further build out the membership table with future 
automations and database associations. Where do we start?

[meg-gutshall]

If you check out this issue (https://github.com/orgs/Virtual-Coffee/projects/29/views/1?pane=issue&itemId=188467570&issue=Virtual-Coffee%7Cairtable%7C3), you can see the progress so far.

[Chuba-code]

...

Data-wise, it would look something like this:

# coffee-table-groups.yml
- id: accountabilibuddies
  name: Accountabilibuddies Group
  slackChannel: announcements
  hosts: [{ name: "Meg Gutshall", handle: "@meg" }]
  status: active

# events/recurring.yml
- id: tues-coffee
  groupId: tues-coffee
  title: "Virtual Coffee Tuesday Coffee"
  timezone: America/New_York
  startLocalTime: "09:00"
  endLocalTime:   "10:00"
  rrule: "FREQ=WEEKLY;BYDAY=TU"   # <— RRULE defines the repeat
  location: { type: zoom, url: "https://zoom.us/j/XXXX" }
  visibility: public
  overrides:
    - date: "2025-11-26"   # cancel pre-holiday
      action: cancel
    - date: "2025-10-31"   # time/title tweak
      action: modify
      title: "Halloween — Wear your Halloween Costume"
      startLocalTime: "09:00"
      endLocalTime: "10:00"

- id: algos-pop-up-jan15
  groupId: algorithms-reading
  title: "Algos Pop-up: Divide & Conquer"
  timezone: America/New_York
  oneOff:
    date: "2026-01-15"
    startLocalTime: "17:00"
    endLocalTime:   "18:00"
  location: { type: zoom, url: "https://zoom.us/j/YYYY" }
  visibility: public

Looks like what the people at SciPy are doing can be leveraged here. They use yaml2ics to covert YAML data to calendars.

[meg-gutshall]

Thanks @Chuba-code! Will look into that package for feasibility.

Right now we're putting things on Google Calendar as a stop gap, but once we build out the CMS portion, this will be good to explore.