Skip to content

Instantly share code, notes, and snippets.

@julsfelic
Forked from rwarbelow/setting_expectations.markdown
Last active February 29, 2016 21:21
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save julsfelic/1ea51f4b9a06a4a678ae to your computer and use it in GitHub Desktop.
Save julsfelic/1ea51f4b9a06a4a678ae to your computer and use it in GitHub Desktop.
Setting Expectations

Setting Group Expectations

Group Member Names: Julian, Alexis, Scott & Admir

  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?
  • Scott: Weekends (Not too early on weekends)
  • Julian: Pretty much open at all times
  • Alex: M,W,F 4-6pm (Workout). Stay till 9-10pm normally. Saturday (Early morning chores) Sunday (past Mid-afternoon)
  • Admir: W (2:30 - 3:00 pm)
  1. How will group members communicate? How often will communication happen, and how will open lines of communication be maintained?
  • Main communication through Slack. Keep slack notifications open
  1. Which feature(s) does each group member want to work on? Which feature(s) does each group member not want to work on?
  • Scott: Project Manager
  • Alex: Ruby / Rails syntax & Front-End
  • Admir: Build out a full feature and work on pushing logic down the stack
  • Julian: Testing, Workflow and Tech Lead
  1. What does each group member hope to get out of the project?
  • Alex: Understand MVC beter. Refactoring within Rails. Challenge w/ Front-End
  • Scott: Embrace the management role.
  • Admir: Solidify Rails knowledge as a hole. Seeding data.
  • Julian: Make a believable project. Professional grade.
  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?
  • Git procedures *
  1. Open up a new branch for a feature

  2. After each passing test. Git commit with descriptive subject and body

  3. When feature is done push up branch

  4. Create pull request with [WIP]. Tag teammates with any notable comments

  5. Look at hound & git commit changes and squash commits with rebase.

  6. If conflicts. Go back to local feature branch. Make sure you have the most updated master and merge master into feature branch. If you run into any conflicts that need the group, go ahead and contact.

  7. Git commit changes. Push up and have group sign off

  8. Scott merges into master

  9. What is expected of group members when they run into problems implementing a feature?

  • Get in contact with Julian. If we can't figure out afterwords, get in contact with instructor / mentor.
  1. How does each group member want feedback (both positive and constructive) to be delivered?
  • Handle it like Gentleman and talk directly to each other. Mid-DTR Sunday.
  1. Is there anything else the group should know about personal work/communication styles?
  • Work in pairs for main features. Work as a group for design and extensions. Julian swears a lot when he codes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment