Google Calendar rate limits

[ojeytonwilliams]

Our current approach of handling all the events with a single Google account is likely to run into rate limits quite quickly. Those limits are documented here: https://developers.google.com/calendar/api/guides/quota https://support.google.com/a/answer/2905486

The hardest limit seems to be

To prevent spamming, a user can send about 2,000 emails to external guests using the Email guests feature.

While that's plenty for a small chapter, it obviously does not scale well - either with activity or number of chapters. Also, they have lower limits unless you have a "subscription account". They do not share what those limits are and it's expensive to get a subscription account.

The possibilities I've considered so far are

1. Create separate accounts for each chapter
2. Stop using Google to send emails
3. Require users to grant Chapter permission to access and update their calendars

None of them are perfect.

Separate accounts

Only works for small chapters (and it's unclear how small).

Do not ask Google to send emails

Scales well, but I do not know if we can provide the same UX as we currently do. Right now, a user can click RSVP and they will immediately get an email from Google with buttons to respond yes/no/maybe. I do not know if we can replicate that.

Ask users for access to their Google calendar

Not all users will have Google accounts, let alone alone want to grant us permission to manipulate them.

Possible next steps

• Handle the errors we get from hitting the limit (we'll want to do this almost no matter what)
• Implement 1. Should be enough for small groups.
• Investigate 2. If we can solve the UX issues this seems like a solid solution.

Discussion is very welcome. We have time to think this through and don't need to rush into an implementation.

[allella]

My feeling is still that Google Calendar integration is not an MVP issue. I believe Quincy has been firm on wanting the integration and that's why it made it into MVP.

We've established that Meetup.com and Eventbrite do not integrate with calendars besides, at best, an "Add to Calendar" button or iCal files in emails that may present "smart" options at the top of some emails. Those methods still rely on the user to manually add an event to the most popular calendars with a click, which is far from perfect, but better than nothing. That method also requires people to manually update their calendar with changes (date/time changes, cancellations, deciding not to attend).

There is a REQUEST method of iCal to send people an invite that will add to their calendar when they click "Yes" to a prompt by their calendar system, but that's also imperfect.

This Google Calendar API integration seems equally as imperfect and even more complex. Plus, it's likely delayed having an MVP that accomplishes the primary feature of Chapter, which is to allow organizers and members to manage scheduled events.

The risk of relying on users to add and edit their own calendar, some with a moleskin in their back pocket, is the unfortunate result of no widely adopted standards for calendars besides what's available in iCal.

While it would be great to have an attendee's calendar magically update, we're still left with only those who use Google Calendar getting the better experience. This means Chapter still needs to accommodate everyone else who doesn't use Google via the website and email. Also, it sounds like we'd still have confusion, or complication, when Google Calendar users delete or changes their attendance from Yes to No. Would those Google Calendar changes be reflected in the Chapter instance or would we end up with two sources of truth on attendance?

For better or worse, people using platforms like Facebook, Eventbrite, and Meetup simply rely on reading the emails and managing their calendar of choice based on what they see in those interfaces or resulting communications. It's not ideal, but it's what people are familiar with because there's apparently no alternative. If there was a better alternative than why don't any of these large event platforms use it?

I don't have a full grasp on the Google Calendar technical capabilities and complexities, but from the outside looking in it seems we're no better off than if we were sending members emails and expecting them to interact with their own calendar and the Chapter instance as they already do with similar event platforms.

@ojeytonwilliams you are clearly more in touch with what's possible, so if you think something can work, then I'm not saying we should abandon the idea. Though, it seems like you're waving a white flag and I'm here to say that I think at least the MVP could exist without Google Calendar magic.

[ojeytonwilliams]

Thanks, @allella, that a pretty fair analysis. I think I can see a reasonable path forwards, but I'll need to discuss prioritization with Quincy. Once I've had a chance to do that, I'll report back here.

[gikf]

Without using attendee list on the Google Calendar side, some option could be sharing calendar with specific people https://support.google.com/calendar/answer/37082?hl=en. It's also limited, but it's once per calendar, instead once per event.

[ojeytonwilliams]

@gikf that doesn't sound like it would really solve the problem. If we share the calendar, the people we share it with would still need to manually accept event invitations, no?

[ojeytonwilliams]

@allella Quincy was happy for me to prioritize getting the self-hosted (email focused) version off the ground.

To that end, I see three main requirements

1. There's reasonably inexpensive and straightforward way to deploy the application
2. The app is viable if the instance owner never enables the Google calendar integration
3. There's a way to customize terms of service, privacy policy and code of conduct since another organisation cannot reuse freeCodeCamp's
4. The logo is configurable.

Does that sound reasonable to you? If it does, I'll break this down into issues.

Just as a quick heads up, I'm considering https://railway.app/ because it's a great alternative to Heroku that should be flexible enough for our needs. If you don't have any objections, I'll get to work setting that up.

[allella]

@ojeytonwilliams yes, I think getting to a point where fCC can "dog food" Chapter to a pilot set of chapters is the best direction. Otherwise, we'll have the perfect app ready in two more years that nobody has ever used.

I'm sure there are technical and documentation loose ends which still need to be completed for the app to be solid enough for live action, but I'm not up to speed on the technical side, so I can't offer a lot on that front.

I can help with the documentation tweaks, like #2138.

I suspect it would be good for you, @gikf @Sboonny to fix/merge the loose end issues and then close other discussions and ideas as "Roadmap" so the issue queue isn't overwhelmed by issues that can wait. I say this because once there are real people using the app I'm sure there will be a flood of new tweak and fix issues that would need more immediate attention than the enhancements or ideas.

[allella]

Also, if we don't have the ability to manage custom privacy, terms of service, and code of conduct, then I'd say to just leave them as a link field and owners can link to those, like the site currently does for fCC.

[Sboonny]

I can create 3 placeholders pages for privacy, TOC, and CoC.

We shouldn't need to change them in freeCodeCamp, so a fork or a template won't have conflicts with this.

Edit: I don't know how this works to be honest, because of my lack of experience, but maybe having a 1 file for the header and 1 file for the footer help too, so people can ignore the changes happening related to them in their repo 🤔

[gikf]

@gikf that doesn't sound like it would really solve the problem. If we share the calendar, the people we share it with would still need to manually accept event invitations, no?

Not necessarily. There wouldn't be invites to specific events on the Google Calendar side. Those with whom calendar would be shared, would see events from the Chapter's calendar, and have it displayed as one of Other calendars at the https://calendar.google.com.

[allella]

@gikf I think the issue Oliver is pointing out is that following a calendar through a link, like with Google's "Other Calendars", will show all events on that remote calendar, and not ones to which someone has become an attendee.

That will be useful to some people, but for others it would show too many events.

[ojeytonwilliams]

Sharing the calendar could be a nice feature, but I don't think it's a direct replacement for sending invitations.