Skip to content

All Meeting Notes

Jump to bottom
Paul Cullen Rowe edited this page Feb 5, 2019 · 25 revisions

Top > Bottom : Recent > Oldest

February 5 - All Team

  • Chuck - Apiary
    • Used to document API
    • https://app.apiary.io/stmbl/editor (requires invite, ping chuck if you don't have one)
    • Using route parameters to execute actions, rather than putting verbs into the api endpoint name (see apiary docs for details)
    • Automatically -pulls routes from- and -pushes docs to- master in our github repo
  • Decision: Monorepo
    • Front and back end will be hosted in the main repo
    • Requires docker config for project
  • Jacob's PR
    • Configs are set up in package.json
    • package.json
      • vue > css > loaderOptions > sass > data
        • This config always imports styles.scss into every scss file
        • Removes the need to import variables etc. into every single scss file
    • Adds End-to-End tests
      • We can add end-to-end tests after a section is stable / feature complete
    • Adds Unit tests
      • we should shoot for 100% coverage on unit tests
    • Router - Generated by CLI, gives us lazy loading :)
    • Observables -
      • Jacob is playing with them
      • We probably won't use the full potential of observables, but we will get good practice
    • '@/' notation on ts imports
      • Gives you access to the src/ level
    • .vscode directory
      • Will suggest extensions that Jacob has tested and work

Jobs

  • Chuck - Leading the charge on setting up back-end boilerplate
  • Jacob - taking Docker Monorepo setup
  • Paul
    • Figure out solution for github notifications
    • Create Decisions manifest
  • Design
    • Meeting Thursday to complete wireframes

Retro

  • Pros
    • Happy with how we're using github
  • Improve
    • Git flow (pure) sucks with github - Use modified version
      • Just use branch naming, and then merge dev into master at stable release points
    • Decisions should be tracked in github Issues
      • Create a decisions manifest - wiki
    • Github discussion notifications on issues sucks - Paul figure out a solution here# January 30 - UX Meeting

Notes and Discussion Items

  • Ben put some rudimentary wireframes together!

  • Is there value in showing the map for the Events view?

  • Check map constraints; if someone scrolls away, can we reset the map?

    Using Google Maps API- think this will allow area constraint or map resetting. (Which approach is better from a UX perspective?)

  • We will need to design admin pages.

  • Orient new users. (Use a cookie?) Are we doing a raffle again? We'll need to let people know they can sign up and what that means. (If they need to sign up, only ask for necessary info- name, and maybe email?) Let users know that they should go to basecamp to check in and get started. Don't require that they sit through a lot of screens in case people have already done this. Maybe provide an option to show check in on the map and navigate to it (but only if the user initiates)

  • Only venues will have ability to edit information in the app.

  • Would it be beneficial to include admin links in the app? (link for venues to edit their logo, image, etc and/or link to edit event details in sched)

  • Decrease clicks by having map still navigable on venue detail pages.

  • What do we do about parts of Dev Week that aren't talks? Can we take the Basecamp category and present that information differently?

  • What happens if a company gives a talks at a venue that's not another space? Can we distinguish venues and companies? Can we sort by companies giving talks?

    NO. API does not provide variables for Company, just Venue. This means:

    1. We will not be able to sort view by organization giving the talks
    2. We can work around this by putting in a general search in case people want to see talks by particular companies (or on specific topics, for that matter) so long as the information is input in Sched

  • Mobile first! Consider how this scales up, though.

January 22 - All Team

Let's start development!

  • 2-2:10 - Overview of Wiki
  • :10-:15 - Review Feature Set
  • :15-:40 - Prioritize Features
    • Core delivery - What's required in Stumbl to be a usable app if we only get 50% done?
    • Ideal delivery - What's a "full product"?
    • Stretch delivery - What would we add if we finish early?
  • :40-3:00 - Choose February owners

Notes

  • Reviewed Wiki and Phases of Production
  • Prioritized Features into Core (C), Full Product (F), and Stretch (S)
    • Probably need to adjust phases of delivery to accommodate
  • Chose Points of Contact (POC) for upcoming work (See Phases of Production to see who's assigned)
Clone this wiki locally