Skip to content

Instantly share code, notes, and snippets.

@kamiboers

kamiboers/boers.rao.soden.little_shop.markdown

Forked from rwarbelow/setting_expectations.markdown
Last active April 18, 2016 21:57
Show Gist options
  • Save kamiboers/630bef5e16be97897731264feeae0d34 to your computer and use it in GitHub Desktop.
Save kamiboers/630bef5e16be97897731264feeae0d34 to your computer and use it in GitHub Desktop.
Download ZIP
Setting Expectations
Raw
boers.rao.soden.little_shop.markdown

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?
  • Kami: happy to stay until evening but don't want to spend forever here. Generally want to be able to take work with us if possible.
  • Chris: has some personal commitments in the afternoon
  • Ashwin: some things on M W at 630 but also doesn't want to stay in basement

  1. How will group members communicate? How often will communication happen, and how will open lines of communication be maintained? Use slack and waffle, remain available and responsive. Let’s organize through waffle. If everyone knows what belongs to them then it will make working easier.

  2. Which feature(s) does each group member want to work on? Which feature(s) does each group member not want to work on? Kami/Chris are comfortable with ruby logic and debugging, no preference about what not to work on. Ashwin would prefer not to work on styling.

  • Chris: Solid on Ruby and spotting bugs. Areas of improvement are figuring out what Rails is doing behind the scenes and understanding how to navigate it. Black box thing. Styling is a weakness.
  • Kami: Solid on debugging and spotting errors. Do well logically. Stlying is something I enjoy. Areas of improvement is nesting scope and conceptualizing paths.
  • Ashwin: Solid on user story to TDD, pushing logic around. Areas of improvment caring about testing edge cases styling.
  1. What does each group member hope to get out of the project?
  • Chris: get passing grades. hone web app skills and learn more about ecommerce sites. Do quality work.
  • Kami: same as Chris. Putting up something that is solid and useable.
  • Ashwin: Good communication.
  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?
  • Merge only as a group, or with agreement between group members. Merge master before pushing up branches, then merge with master to avoid conflicts. Kami will be in charge of ensuring that merges occur as necessary and that they are communicated to other group members.
  1. What is expected of group members when they run into problems implementing a feature?
  • Try your best to solve a problem on your own but then communicate with other group members and ask for help when needed.
  1. How does each group member want feedback (both positive and constructive) to be delivered?
  • Specific, actionable and kind.
  • Provide feedback during code review.
  1. Is there anything else the group should know about personal work/communication styles?
  • communicate on professional level and move forward based on consensus between group members.
  • Ashwin prefers not to continue to hammar away at bugs as a group when this strategy is unsuccessful.

  1. Project Manager: Ashwin Rao

  2. Planned Extensions or additional features

  • thorough business modeling: late fees, turnaround time, item availability —> email alerts
  • product reviews
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment