Improved data management

[geobrando]

Following up on #92, there should be some discussion about adding some complexity and expanding from a single google sheet to track Maptime data to something that resembles an actual database. The reasons being:

1. It's too difficult to keep track of chapter data as well as organizer data in a single table
2. The desire to record and analyze maptime metrics (#62)
3. Ability to easily identify inactive chapters (#91)
4. The need for a system that will scale as Maptime continues to grow while manpower resources remain static

   Current data sources

   • The main chapter google sheet (private) that contains some chapter and organizer info, chapter inquires, and formal chapter requests being populated by the web form at maptime.io/start.
   • chapters.json, which is the primary source for general chapter and organizer data. It's being maintained collectively by the small onboarding team and by organizers comfortable adding their info to it with pull requests. Used to populate the map and chapters list at maptime.io/chapters
   • Post-event surveys submitted by the google form. Not sure if this data is being used in any substantial way and I assume are not filled out on a regular basis by most chapters (including my own :smile: : )
   • Event information from the many chapter meetup.com pages (or similar sites)
   • Qualitative event data in the form of Slack messages, social media, or blog posts

     Database design

Here's one idea for a database with potential fields. Each could have a unique key with an ID or one could be generated from other fields. Given the general loose structure of Maptime and lack of resources, it will be difficult or perhaps undesirable to track some of these in a database. There could also definitely be others...

1. Chapter table - City, Region, Country, chapter name, inception date, email, twitter, facebook, meetup, Status (inquiry/good standing/on probation :wink: /defunct), Notes
2. Organizer table - Name, chapter, email, twitter, active?
3. Event table - Event date, Event title, event type (instructional/hack or project night/etc), # of attendees, language, female-to-male ratio, sponsor, organizer recap, attendee feedback summary, [other standardized fields that might be part of an event survey]

Another option could be a separate table for chapter inquiries and keeping this out of the chapters table

Database platform ideas

• Expand from using a single sheet to multiple google sheets. Google has Google Visualization API Query Language which is a subset of SQL and can be used to update and run queries.
• Use Google Cloud SQL (a MySQL database in Google's cloud). This costs money but could be an option.
• PostgreSQL or some other database hosted on AWS or elsewhere

  Considerations

• Should have a user-friendly interface by which organizers can easily add and update their own chapter data
• Should not be duplicative
• Could use github as a component but not the primary source. I like chapters.json for many reasons.
• Need to reconcile desire to keep some information private while still allowing organizers to update

@maptime/owners