Meeting Notes December 15, 2019

Before you dive into the notes, please make sure you have read the following:

• Chapter's README
• Chapter's Vision

In Attendance

• Project Lead: Quincy Larson
• Cecilia Constantine
• Fran Zekan
• Jim Ciallella
• Nikhil John
• Timmy Chen
• Ayotomide Oladipo
• Vaibhav Singh
• Jonathan Seubert
• Aryan Jabbari
• Madalena Aza
• Vivek Agrawal

Database and API Update

• Fran gave an update on the database and critical path
• Database work is effectively done. The models are done, migrations are done, initial schema is defined, seeds are initialized, but seeds still need to created.
• There is one open PR related to the database migrations.
• We can start working on the API.
• Fran showed an example of the Swagger documentation. We need to add more descriptions and rename some of the titles.
• Npm install shows vulnerabilities but only 1 is from our project. The other 6 are from speccy, which are not going to be fixed quickly.
• Quincy suggested switching to another API documentation tool that doesn’t have vulnerabilities because these can be a red flag on projects that keeps people from participating.
• Fran suggested we consider hosting Swagger documentation on a website host, but Quincy preferred localhost since not everyone will have internet all the time.
• We took a vote and agreed to use on a npm Swagger linter package, such as Swagger UI Express, running on local node server. This was assigned to Nikhil.

Review of Other Pull Requests and Issues

• The HTML rendering issue was closed. Quincy suggested plain-text emails are easier to create, support, and have better open rates.
• #114 was closed in favor of the existing individual UI specific issues.
• #255
  • Timmy was concerned about laying out basic tasks which don’t necessarily have as many blockers or dependencies.
  • Quincy rehashed that earlier blocking issues were database related and should be less of an issue.
  • It was suggested to label issues as blocked or unblocked to help newcomers.
  • We also talked about adding labels for each user type: user, admin, organizer
  • Timmy said the Project board helped with some of his original concerns.
• Fran is going to start working on API issues like #102 and perhaps another related issue, even though they don’t have mockups
• The mockups are now a blocker.
• Quincy suggested using placeholder content when there are no mockups. The mockups can be taken into consideration later.
• Quincy suggested the the IFTT admin user interface as a simple single-column design, since we’re building mobile first. Large desktop or tablet displays are less of a concern since mobile designs will also work on larger displays.
• It was suggested to have navigational UI elements, like large buttons, over a “hamburger menu”.
• Quincy likes the idea of limiting the number of actions on the screen to avoid confusion.
• In particular, Quincy suggested using a “wizard” format, at least for the initial setup steps, as much as possible to eliminate ambiguity.
• Quincy typed out a simple user story workflow, using an Admin’s perspective, as an idea of how to start thinking through the UI issues.
• Vivek suggested the admin and organizer would need to see a dashboard with many options, at least after they have gone through the wizard. Quincy thought we should go with wizards over dashboards for the initial setup.
• Jonathan suggested having the designers think through the user flows and come up with complete ideas on their own personal accounts and then share these on the issues.
• It was suggested we continue thinking through the user flows, empathize with the user, and “get something down on paper” and share something on the related Github issue(s).
• Sharing our ideas, mockups, drawings, or anything that inspires more conversations is more immediately valuable than codifying process and tools. Though, everyone is welcome to use the tools that allow them to get their ideas out in the open.
• If / as tools or processes prove to be helpful then we’ll adopt the ones that work for this project.
• Examples of recent conversations which have helped to quickly move along UI issues and provide a basic for detail focused mockups:
  • #107 - decisions were made on missing fields in the schema and how to account for event vs chapter notifications
  • #274 - productive conversation about which UI elements to use for subscribing or unsubscribing
• #253 - Nikhil will review the Swagger-related changes.

Next Meeting

• Ping Quincy on Discord for meeting invites.
• There will be a design meeting on Saturday December 21, 2019 2:00 PM - 3:00 PM to share mockups, but anyone is welcome to join.
• The next Chapter meeting will be announced for the first week of 2020.