Skip to content

Instantly share code, notes, and snippets.

@NickyBobby
Forked from rwarbelow/setting_expectations.markdown
Last active February 29, 2016 21:19
Show Gist options
  • Select an option

  • Save NickyBobby/116d83e610a26c812b3c to your computer and use it in GitHub Desktop.

Select an option

Save NickyBobby/116d83e610a26c812b3c to your computer and use it in GitHub Desktop.
Setting Expectations

Setting Group Expectations

Group Member Names: Nick D, Nate, Chad

    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?
  1. Group members are flexible to work anytime. Nick has some meetups that he wants to go to but other than that he is free. We don't want to work past 9 o'clock during the week. Time commitments have been worked out.
    1. How will group members communicate? How often will communication happen, and how will open lines of communication be maintained?
  1. Communication will mainly happen on Slack but we will leave informative comments on all pull requests.
    1. Which feature(s) does each group member want to work on? Which feature(s) does each group member not want to work on?
  1. Chad loves API's, hopefully we can incorporate them in this project. We all want to work on general rails stuff, so it'll be a good mix of everything. Nick wants to work on styling more so he will focus on that as well.
    1. What does each group member hope to get out of the project?
  1. Chad wants to get better with his git workflow, would love to have an app that's fully marketable, and practice with API's. Nate would like to have great planning structure, would love to have something worthy of showing off, and becoming more comfortable with refactoring. Nick would like to have something worthy of showing to other people as well, and something that has a practical real life application.
    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?
  1. The Git workflow is basically whoever makes the pull request to merge to master can not confirm that merge. It needs to be verified by another team member and that team member needs to send out a message on Slack saying that the merge is complete.
    1. What is expected of group members when they run into problems implementing a feature?
  1. The group has decided that you should not struggle with a single for more than 40 minutes. Obviously if it's a simple issue we don't need to wait 40 minutes to ask someone for help, but it should be no more than 40 minutes without reaching out to another team member.
    1. How does each group member want feedback (both positive and constructive) to be delivered?
  1. Daily feedback updates to make sure everyone is on the same page. And a more formal feedback for each team member at the end of the project
    1. Is there anything else the group should know about personal work/communication styles?
  1. Slack and Github will be the main way we communicate about project issues, in addition to face to face conversations.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment