Skip to content

Instantly share code, notes, and snippets.

@alfosco
Forked from Carmer/setting_expectations.markdown
Last active February 21, 2017 22:32
Show Gist options
  • Save alfosco/05568080fff1f94bd0a437b08ee11b0b to your computer and use it in GitHub Desktop.
Save alfosco/05568080fff1f94bd0a437b08ee11b0b to your computer and use it in GitHub Desktop.
Setting Expectations

Setting Group Expectations

Group Member Names: Alex(PM), James, Max

  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?

    • After 10PM shutdown. Not in the mornings. Gym time on weekends. Potential cookout. Alex: Friday or Saturday going out. Max after 6:30PM on Thursday.
  2. How will group members communicate? How often will communication happen, and how will open lines of communication be maintained?

    • Slack, phone numbers. Texting. WhatsApp. Stand-ups everyday.
  3. Which feature(s) does each group member want to work on? Which feature(s) does each group member not want to work on?

    • Max on styling. Everyone gets some of everything. James would like to work on authentication / authorization. Model testing, controller testing.
  4. What does each group member hope to get out of the project?

    • Want this project to be something we can put on LinkedIn; a link to a website. Preparation for the final assessment. Git workflow really on point for outside viewing.
    • Improvements: nested routes, styling.
  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?

    • Issues, a person is assigned an issue, check out a branch on master. Branch names are based on the tests name. Once the test passes, tag each other on the pull request, view pull request, then merge.
    • Strong commitment to code freezes.
  6. What is expected of group members when they run into problems implementing a feature?

    • Shout out into the channel. Timebox. Errors we should reach out immediately.
  7. How does each group member want feedback (both positive and constructive) to be delivered?

    • Don't be dramatic.
  8. Is there anything else the group should know about personal work/communication styles?

    • Database changes, commented and pointed out.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment