## Setting Group Expectations

Group Member Names: Liam, Mike B, Kali, Brandon

1. When are group members available to work together? What hours can each group member work individually? Are there any personal time commitments that need to be discussed?
- Brandon try turing tutoring Saturday 9 to 4
- Mike B.
- Liam not available on Sunday
- Kali busy friday night / (?) Saturday night open

2. How will group members communicate? How often will communication happen, and how will open lines of communication be maintained?

- Skype/google voice/google hangouts etc. at least once a day if we dont interact in person
- Use slack for primary communication
- Kali has a preference for in person collaboration

3. Which feature(s) does each group member *want* to work on? Which feature(s) does each group member *not want* to work on?

- ActiveRecord / Analytics
  - Everyone loves analytics

- View / CRUD / Sinatra / ERB
  - Mike is OK with it
  - Liam hates this

- Rspec / Capybara
  - Liam is interested
  - Brandon likes this
  - Mike hates testing

4. What does each group member hope to get out of the project?
  - Liam: Understand and be proficient/comfortable at each individual thing.
  - Mike: Diving into databases and making those analytical connections.  Because he is a nerd.
  - Kali: Gain a better understanding of how each component of a web application works together.
  - Brandon: Learn stuff.

5. What is the agreed upon Git workflow? What project management tool will be used? What is the agreed upon procedure for conducting code reviews before merging into master: who will review pull requests, and when?

- Git
  - Use it.  Frequent commits
  - Branches for days.  Don't work on master
  - Don't work on master.
  - Decent branch names - no words that are hard to spell
  - Merge master into branch before merging branch into master
  - Merge conflicts - Two person check

- PM Tools
  - Waffle

- Code reviews
  - Have another person review before merging into master
  - Ask about a particular file / line number when you see something that could be changed.

- Who reviews pull requests
  - If there is a person whose work will be impacted by yours ask them to review it
  - Brandon will act as PM to ensure people are aware of what others are doing.
  - Otherwise just ask in slack if someone can review it.

6. What is expected of group members when they run into problems implementing a feature?
  - Dont be scurred
  - Throw out an @everyone
  - Dont beat your head against a wall for more than 20 minutes.

7. How does each group member want feedback (both positive and constructive) to be delivered?
  Kali: Verbally.  As soon as possible.  Doesn't have to be private.
  Mike: No preference.  Doesn't have to be private
  Liam: Let him know if something was messed up.  Doesn't have to be private
  Brandon:  Same as above.  Public shame is productive.

8. Is there anything else the group should know about personal work/communication styles?
  Kali: Direct collaboration.  Try to be off earlyish 9-10 PM.
  Mike: Divide and conquer.  Try to be off computer by 10 PM.
  Liam: Divide and conquer worked better - wants to explore driver-navigator.  Sunday afternoon mostly non available
  Brandon: Driver navigation is awesome, but divide and conquer is okay too.  Try to be off earlyish 9-10 PM.

9.  What should we do tonight?
  Plan out how we are going to divide and conquer the project.  Set up initial waffle cards.