New Events Calendar Service

[meg-gutshall]

Summary 📆

The Maintainers have decided to move away from the current combination of CraftCMS and Airtable to a standalone events calendar plugin in order to cut down on monthly costs.

Goal 🎯

Transfer the backend event CRUD actions and calendar rendering away from paid services as quickly as possible to something equivalent or better featured that's maintainable and has a low learning curve.

Calendar Service Needs

• Written in JavaScript or TypeScript
• Renders event title and description on calendar
• Supports recurring events
• Calendar feeds per event type

(@Virtual-Coffee/maintainers, let me know if I'm missing anything here)

Candidate Calendar Services 💬

I've reviewed quite a few libraries and gathered a selection that may work for our purposes. I'm interested in thoughts on those listed below (likes/dislikes, pros/cons, etc.) as well as any suggested alternatives to be considered.

• FullCalendar
• EventCalendar
• schedule-x
• ToastUI Calendar

---

cc: @JoeKarow @danieltott @tkshill @BekahHW @nickytonline @jonathanyeong

[meg-gutshall]

This won't change the display on the VCIO website. This is meant to replace the calendar and event creation service in CraftCMS and Airtable on the admin side. Therefore, any calendar displays brought in by a new service will be admin only.

[nickytonline]

If we're no longer using CraftCMS or Airtable, where is the event info stored or do we already have a DB in the project? All these projects seem to be just the UI.

[meg-gutshall]

Netlify!

[nickytonline]

Ahh you mean Neon DB on Netlify?

[meg-gutshall]

I believe so. @JoeKarow had the idea and thinks we'll stay well under the allotted free tier storage of what Netlify gives us.

[JoeKarow]

@nickytonline Yeah, I think that's the one.. either that or using one of Cloudflare's databases - they have a very generous free tier.

[BekahHW]

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]

@BekahHW, thank you for writing up this detailed proposal. I like where this is headed in that the data will have a single source of truth.

I think my original post was a bit incomplete since it's only dealing with the admin view of the calendar service, assuming that we'll just move the data from Airtable to Netlify. Yours is more comprehensive.

I'll begin to gather the attributes we'll need for the CTG listings and look into the docs for the other tools you mentioned. We can add on one of the calendar services for admin (if needed) once we get your single source of truth solution set up.