Skip to content

Instantly share code, notes, and snippets.

@slota
Forked from rwarbelow/setting_expectations.markdown
Last active November 9, 2015 17:23
Show Gist options
  • Save slota/d44de9b674138a04d60b to your computer and use it in GitHub Desktop.
Save slota/d44de9b674138a04d60b to your computer and use it in GitHub Desktop.
Setting Expectations

Setting Group Expectations

Group Member Names:

  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?

Shannon - Available whenever but doesn't like to work past 10 o'clock at night, Amber - Has no real restrictions on her time, likes to be home and sleep John - Has bitcoin monday at 6 and CU game Friday night, good to go

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

Shannon Amber and John - We all like slack, Shannon is an oversharer,

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

A - Maybe we should spit it up, authentication was a lot of referencing, CRUD easier S - Aaron took materialize on last project and Shannon took refactoring, ok with anything but bitcoin, only caveat is that Shannon is really good at CSS, but things, in her opinion, don't look good, has ecommerce management experience so wants to help with backend user stories J - Feels that splitting up work might make us go slower if John has to do it solo

  1. What does each group member hope to get out of the project? J - Learn more about everything A - Excited to build something a little more new and uncomfortable, build something super sweet

  2. What is the agreed upon Git workflow? Who will review pull requests, and when? What project management tool will be used? S - Rule to have is nobody can merge their own pull requests, but annoying if people aren't there to push, anyone can reivew pull requests if not their own, lifes waffle, super helpful to use waffle when it automatically gets pushed by git, need a few details to make it automatic, when you're working and you think of something and screw up a single branch, make a card when think of something different A - Annoying when their are merge issues, also likes waffle, wants to organize feature tests J - Agrees with not merging your own work, stopped using waffle on trafficspy

  3. What is expected of group members when they run into problems implementing a feature? A - Troubleshoot for a bit, message the group pretty quickly, if group doesn't message back... don't keep working on something that can't get fixed, message and get some help on it, take a pomodoro, also make sure we have frequent check-ins, let's pair if we get stuck, but need to make sure we understand each other's code, S - If group doesn't message back, pass it on to someone else, ask Robbie for help, stack-overflow, plenty of feautres to work on if we get stuck on certain things, go over code to help group members understand

  4. How does each group member want feedback (both positive and constructive) to be delivered? J - Just let me know, whatever way is easier A - If I'm being a dick, whatever easiest is for person that's mad, let me know

  5. Is there anything else the group should know about personal work/communication styles? S - Crazy OCD and organized, let me know if I get too in the weeds about organization like with waffle, make sure that we split up commits, make sure we alternate who plugs in for at least jobs, likes to meet at Turing A - Likes that Shannon is crazy organized, how do we want to do pairing, J - Not OCD super organized, I like to pair, and I like to type as much as possible, likes to meet at Turing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment