Skip to content

Latest commit

 

History

History
158 lines (116 loc) · 10.9 KB

team_contract.md

File metadata and controls

158 lines (116 loc) · 10.9 KB

Team Working Contract

Below is a teamwork contract template adapted from Carnegie Mellon University. It is divided into several sections, and it is expected that each group will spend some time generating at least 5 points for each section that everyone agrees to.

If you are not able to agree on these points, it is a sign that your group may become dysfunctional, and you should seek advice from me (the course instructor) ASAP to resolve and mediate the discussion.

Team Members

Name GitHub Handle
Person 1 @nom0786
Person 2 @jonahedmundson
Person 3 @sahaavi
Person 4 @freinric

Working Hours

Team members agree that standard hours of work are: 6-8 hours anytime of day between daily group meeting, to aim for 32 hours weekly. Weekends are standard days off, unless work is required to meet a deadline.

Participation

All team members agree to fully participate in all aspects of the project. To accomplish this goal, below are five concrete actions that we all agree to take:

  1. Attend all team meetings and arrive on time.
  2. Actively listen to each other and encourage open communication.
  3. Share resources and information relevant to the project.
  4. Stay up-to-date with project progress and contribute regularly.
  5. Be open to constructive feedback and suggestions from team members.

Communication

All team members agree to communicate openly and transparently during the project. To accomplish this goal, below are five concrete actions that we all agree to take:

  1. Use a communication platform that works for everyone, such as Discord, Slack or Microsoft Teams.
  2. Respond to messages and emails in a timely manner, especially those that require urgent attention.
  3. Clearly communicate project goals, expectations, and deadlines to all team members.
  4. Hold regular team meetings and check-ins to discuss progress and resolve issues.
  5. Have no hesitation in asking questions, and take concerns of group members seriously and respectfully.

Meetings

All team members agree to meet regularly during the project. To accomplish this goal, below are five concrete ideas that we all agree to regarding scheduling and frequency of meetings:

  1. Group meeting daily at 10 am on Discord, weekly meeting with client Fridays at 10 am on Microsft Teams, weekly meeting with capstone instructor and TA tba.
  2. Set an agenda for each meeting and share it with all team members beforehand.
  3. Rotate the responsibility of leading meetings so that everyone has a chance to facilitate discussions.
  4. If team members cannot attend a meeting, they should notify the rest of the team in advance and catch up on what they missed.
  5. Use meetings to discuss progress, resolve issues, and set goals for the next period.

Conduct

The code of conduct we have chosen is in the Code of Conduct document. All team members agree to following the code of conduct, and below are five concrete escalation steps that we all agree to follow in the event that the code of conduct is violated by any member of the group (Step 1 is the first thing you will do, and Step 5 is the last thing you will do).

  1. The team member who is affected by the violation should speak privately with the member who has violated the code of conduct and try to resolve the issue.
  2. If the issue cannot be resolved, or if it is too difficult for the team member to confront the violator, they should discuss with other team members.
  3. If the issue is still unresolved, the team member should report the violation to the TA, who can take further action.
  4. If the violation persists or if it is serious enough, the TA may escalate the issue to the course instructor or supervisor.
  5. In the event that none of the previous steps have resolved the issue, the team members may agree to leave the matter to the discretion of the course instructor or supervisor to mediate the conflict and determine the best course of action for the team.

Conflict Management

Despite our best intentions, conflict may invariably arise within teammates. Discuss amongst your team some conflict mitigation strategies (feel free to search online if needed) and come up with 5 strategies all members of the team agree to follow in the event there is a conflict within the group. You may also include things you will NOT do in the event a conflict arises.

  1. Strategy 1: Use active listening techniques to ensure that all team members feel heard and understood.
  2. Strategy 2: Focus on the problem, not the person, and avoid personal attacks or blame. Respect group members at all times.
  3. Strategy 3: Seek to understand the underlying concerns and interests of all parties involved.
  4. Strategy 4: Brainstorm possible solutions and evaluate them objectively to find the best option.
  5. Strategy 5: If needed, seek the help of a neutral third party, such as the course instructor or a TA, to help resolve the conflict.

Deadlines

All team members agree to the following conventions around course deadlines:

  1. Convention 1: All team members will prioritize meeting deadlines and will inform the rest of the team as soon as possible if they are unable to meet a deadline.
  2. Convention 2: The team will work together to set realistic deadlines for each project milestone and will adjust them as needed based on progress and unforeseen circumstances.
  3. Convention 3: In the event that a team member misses a deadline, they will communicate with the rest of the team to discuss the impact and any necessary adjustments to the project plan.
  4. Convention 4: The team will keep track of all deadlines and progress using a shared project management tool or platform (Notion).
  5. Convention 5: All team members will be responsible for reviewing and submitting final deliverables by the designated deadlines.

Git Workflow

There are many git workflows possible when working on a team project with many moving parts. I suggest you discuss in your group some possible Git workflows. Here is a brief primer on some common options. I suggest reading them, understanding them, and then selecting one. You can explore and choose any you like, but if you cannot decide, I suggest using the "Feature Branch Workflow".

All team members agree to the Feature Branch workflow, and the following conventions:

  1. Feature Branch Workflow: All team members will work on their own feature branches and submit pull requests to the main branch once their work is complete and has been reviewed by at least one other team member.
  2. Main Branch Protection: The main branch will be protected to prevent direct pushes, and only pull requests that have been approved by at least two team members will be merged.
  3. Code Reviews: All pull requests will require at least two team members to review the code before it can be merged into the main branch.
  4. Branch Naming Convention: All team members will use a standardized naming convention when creating feature branches to ensure consistency and clarity. For example, the branch name could include a brief description of the feature being worked on and the initials of the team member working on it.
  5. Deadlines: All pull requests must be submitted at least two days before the project deadline to allow time for reviews and final revisions.

Final Reflection on Workload Distribution

** This section should be completed AFTER Milestone 4 is done and submitted! Only one is needed PER group. **

In this section we will ask you to self-report the workload distribution to various categories of tasks. For each of the categories, we want you to report the approximate workload distribution, split by the milestone.

Here are the tables you are expected to complete (the first one is pre-filled in so you can see what we're expecting):

Milestone 1

Category Team member 1 Team member 2 Team member 3 Team member 4
Repository Setup 60% 40% - -
Sketch 20% 25% 25% 30%
Documentation 10% 10% 40% 40%
Project Management 50% 50% 0% 0%
Troubleshooting - - - -

Brief notes/explanations (optional):

  • No troubleshooting was needed for Milestone 1
  • Member 1 and Member did most of the repository setup, whereas 3 and 4 did most of the documentation

Milestone 2

Category Team member 1 Team member 2 Team member 3 Team member 4
Documentation/Reflection
Writing new code
Code Reviews/editing
Project Management
Testing & Troubleshooting

Brief notes/explanations (optional):

Milestone 3

Category Team member 1 Team member 2 Team member 3 Team member 4
Documentation/Reflection
Writing new code
Code Reviews/editing
Project Management
Testing & Troubleshooting

Brief notes/explanations (optional):

Milestone 4

Category Team member 1 Team member 2 Team member 3 Team member 4
Documentation/Reflection
Writing new code
Code Reviews/editing
Project Management
Testing & Troubleshooting

Brief notes/explanations (optional):