- When are group members available to work together? What hours can each group member work individually?
We'll get here at 9 AM and work whenever we have worktime. We're all open to staying here after school and we'll determine how much we'll work individually
- Are there any personal time commitments that need to be discussed?
We'd like to get the initial setup today and be able to take the day to work on other tasks but other than that we're all pretty open.
- How will group members communicate? How often will communication happen, and how will open lines of communication be maintained?
Daily Stand Up every morning to make sure that everyone's on the same page. We'll try to work in the same room even if we're working individually so that we can walk over whenever we need to talk to each other. If anyone is working remote we'll use Screenhero and Slack.
- Which feature(s) does each group member want to work on? Which feature(s) does each group member not want to work on?
Too early to tell. We'll discuss this whenever we get the stories.
- What does each group member hope to get out of the project?
Daniel - I want a project that I would be happy to include on my personal portfolio.
Drew - I want to get a beautiful, working project that's totally passing with 3's and 4's and a project that I would be proud to show off in my professional portfolio.
Laszlo: a complete, finished project that I can include in my personal portfolio. The implementation should successfully pass the Turing project evaluation. The implementation should have clean and well structure code.
Nick - Create a project that fulfills requirements, some super-neat extensions, and polished and ready to put on my portfolio to impress prospective employers.
- 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?
We'll use Waffle as a project management tool. As for code reviews the person submitting a pull request is expected to make sure that all tests are passing. All of the team members will then comment on the pull request to okay it and the last one will merge it. The person submitting a pull request should never merge their own pull request. NEVER WORK ON MASTER BRANCH.
- What is expected of group members when they run into problems implementing a feature?
Reach out to other team members whenever they run into problems implementing a feature
- How does each group member want feedback (both positive and constructive) to be delivered?
Daniel: Direct feedback works best with me. If there's anything that I'm doing to bother someone please let me know.
Drew: just give the feedback to me straight. Don't bushwhack or dance around the problem; address it and re-DTR if necessary.
Laszlo: feedback, suggestions are always welcome. If anyone thinks that I am going to the wrong direction, let me know as soon as possible so I can correct early on. Praise is also always welcome
Nick: Direct feedback works best with me, just tell me.
- Is there anything else the group should know about personal work/communication styles?
Drew: I am always open for communication at all times. If it's after 9 pm, it might be a little bit before I respond.
Laszlo: I prefer frontloading the work, to position ourselves well for a final push and leave sufficient time for refactoring and covering corner cases.