This repository has been archived by the owner on Jun 9, 2023. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 359
Meeting Notes November 7, 2020
Jim Ciallella edited this page Nov 8, 2020
·
10 revisions
Before you dive into the notes, please make sure you have read the following:
- Quincy Larson - Dallas, TX USA
- Jim Ciallella - Greenville, SC USA
- Jonathan Seubert - Beaverton, Oregon USA - UX / Design
- Oliver Eyton-Williams - Brussels, Belgium - Full-time with freeCodeCamp
- André - Stuttgart, Germany - Frontend Engineer
- Fran Zekan - Zagreb, Croatia. University student and board game designer
- Patrick San Juan, Software Engineer at Moody's Analytics, SF Bay Area USA.
- Katie Noland - Denver, CA USA
- Randy Dawson - Santa Clara, CA USA
- Fran, who stubbed out much of the early API and front-end, has been busy with a number of projects. He hopes to return to being active on the project next week.
- The pandemic slowed the development earlier this year, but PRs and progress has continued.
- Quincy reiterated there are freeCodeCamp chapters in countries, like China, which have a handle on the pandemic. Those chapters are already having in-person events and can help be beta-testers for the MVP.
- A few pull-requests from @katien have been merged in to add URL-related fields to better accommodate virtual events and/or video streams.
- Fran said the API and core admin functionality for CRUD (create, read, update, delete) of events is mostly finished. The user-facing interfaces have not been developed. Fran suggested this as the next action item for someone to tackle.
- Jim shared thoughts on event role authorization and notes are stored on #270 for future conversations once authentication is in place.
- Ryuno-ki has worked on a few front-end items and needs to learn more about Apollo and GraphQL to proceed.
- Randy asked if contributors are using Docker or the stand-alone. @katien is using Docker just for the database. Jonathan and Fran haven't been using Docker. Fran and Patrick mentioned MacOS is slow with Docker. @katien suggested adding Redis to Docker so people could use it for just the database if they want to continue hot-loading the local code. Fran said we setup Docker to help Windows users avoid having to install PostgreSQL.
- Fran suggested having a full-docker, semi-docker for just databases, and standalone. Fran said there is a IS_DOCKER flag in the .env and that may need some database commands to work correctly with or without docker-compose exec.
- Oliver suggested trying Github Actions to help auto-build the development environment. This would be similar to what freeCodeCamp is doing.
- Fran mentioned Github Codespaces as a potential tool to spin up a Linux Virtual Machine (VM) with VS Code as a one-click tool. However, it may cost money to the contributor.
- Quincy said Gitpod is another similar tool that's been used by freeCodeCamp. Gitpod has a free 50 hour tier. He's prefer to work with a familiar tool. Oliver will look into this issue and we have a conversation started on issue #384.
- Ryuno-ki asked about using Google Authentication because it would be blocked in countries like China.
- Quincy initially said we'd target Google for the MVP authentication because there are common Websocks client to work around firewalls. However, it was later decided that Google integrations may cause restrictions which harm long-term adoption of the platform.
- For China, there's likely a clone with 1-to-1 functionality matched to Google Authentication and Google Calendar (possibly WeChat Auth). Quincy has Chinese colleagues if we needed to reach out for suggestions.
- It wasn't a suggestion, but Quincy reiterated that Auth0 is not a viable option as it would require Chapter instances to setup with a paid Auth0 account whereas using Google Auth would simplify the application's authorization.
- We talked about limiting the number of 3rd party services, specifically Google Auth. Google Auth does make a lot of things simple, but it's not available in all countries, some users resist Google accounts. Also, China and some government agencies usage would potentially not use Chapter because of data retention or other restrictions linked to a Google integration.
- Patrick was fine with using email for authentication, instead of Google, which would make PR #411 no longer necessary. We need to create an issue for email authentication if that's definitely the new direction.
- Even without integrating with Google, it is simple to have an Add to Google Calendar button and an iCal link to make allow attendees to add the event to their preferred calendar app.
- Quincy was interested in direct integration with Google Calendar so an attendee's calendar would be updated if events are changed or cancelled.
- Fran asked about only using email authentication and event notifications, plus using Webcal for dynamically allowing users to integrate a calendar feed into their calendar tool of choice. He mentioned Google Calendar (via Other Calendars -> Add -> From URL) accepts webcal:// or https:// links to keep the event in sync based on regular synchronization interval. This would be instead of a one-time importing of an iCal file or an "Add to Google" button (example) that uses a query string to save the event to Google but where never updates again.
- Issue #436 was created to address this MVP webcal feature. See "Subscribe to an Online Calendar" section for an example of how this works with Google Calendar.
- Jonathan continues to work on the email, but is having issues with the TDD (test-driven development) framework producing errors. Fran has been set as the reviewer for #428. Jonathan feels he can get the emails working in the coming weeks once he gets past the TDD error.
- Fran said for sending email, it's not necessary for everyone to setup a 3rd party email transaction service. Smaller groups would have the option to route emails through a well-known email services like Google, Yahoo, QQ, etc. This would be in addition to allowing more manual configuration of using SMTP.
- Jim mentioned relaying email through a well-known mail host is a good option for development or small groups, but it doesn't eliminate SPF and DKIM requirements if the "From" email address uses an organization's domain. For instance, an organization like freeCodeCamp is very unlikely to relay mail through a Google or Yahoo server. Instead, the instance owner would still need to setup SPF, DKIM records for their desired 3rd party email transaction service for emails to come from @freecodecamp.org.
Quincy will share an invite on the Discord #general channel for the next meeting at the same time once we establish another meeting is warranted.