Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save robbiejaeger/8b581fab0401d43e6f0341243e226582 to your computer and use it in GitHub Desktop.
Save robbiejaeger/8b581fab0401d43e6f0341243e226582 to your computer and use it in GitHub Desktop.
Setting Expectations

Setting Group Expectations

Group Member Names: Kerry Sheldon, Karina Gonzalez, Robbie Jaeger

  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?
  • Everyone can be at Turing until 6:00-6:30pm and then work from home individually. There are no big personal time commitments foreseen at this point.
  • If we want to leave at 6:30pm, make sure we stop development/code work at 6:00pm and then wrapup the day together and plan next steps (so we can actually end at 6:30pm).
  • Re-DTR every other day to make sure everyone is on the same page and things are going well.
  1. How will group members communicate? How often will communication happen, and how will open lines of communication be maintained?
  • If not at Turing, use a group Slack direct message. If not getting responses from Slack, then use personal cell phones if necessary.
  • Spend the first portion of work time each day reviewing what everyone got done the day before and the plan for the day.
  1. Which feature(s) does each group member want to work on? Which feature(s) does each group member not want to work on?
  • Karina wants to make sure she works on using Bootstrap. All group members don't have any very strong preferences to work on specific features.
  1. What does each group member hope to get out of the project?
  • Karina wants to drive more to be able to learn from others in the group.
  • Kerry wants to make sure we can divide up pairing and get better at dividing work tasks (so that three people aren't just staring at a screen together).
  • Robbie wants to be familiar with RSpec feature, model, and controller testing syntax
  1. 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?
  • Always work off branches, and never commit or push directly to master
  • Pull master from github (origin)
  • Checkout a new branch
  • Work on the new branch, commiting frequently
  • When finished with branch work, git pull origin master from your branch, take care of any conflicts
  • When ready to push code to github, be sure that everything is commited on your branch (stash unwanted changes) (all tests should pass at this point)
  • Push your branch changes to github, create a pull request
  • The group reviews the pull request and then merges to master
  • Pull down master from github
  1. What is expected of group members when they run into problems implementing a feature?
  • After 45 minutes of being completely stuck, reach out to other group memebers to get help.
  1. How does each group member want feedback (both positive and constructive) to be delivered?
  • Tell the other person privately (in person).
  1. Is there anything else the group should know about personal work/communication styles?
  • If Karina gets really quiet in a group setting, ask her how she is doing just to make sure we're on the same page. Kerry has a hard time working at Turing when a task requires concentration. Robbie likes to read through new tasks that the group gets before the group starts working together on them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment