Skip to content
This repository has been archived by the owner on Sep 12, 2023. It is now read-only.

Latest commit

 

History

History
100 lines (70 loc) · 4.9 KB

team_contract.md

File metadata and controls

100 lines (70 loc) · 4.9 KB
Raw

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 @aishwaryasharma10
Person 2 @harpreetkaurguglani
Person 3 @Jagdeep14

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. We will work together to divide tasks evenly.
  2. We will all show up to meetings.
  3. We will do our best to communicate effectively.
  4. Make an effort to document code so others can edit it later.
  5. Make sure your code is reusable/efficient, and follows best practices.

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. Actively share ideas and discuss in the group chat.
  2. Make detailed and descriptive commit messages.
  3. Alert teammates when you make a pull request so we can all talk about it.
  4. Reach out if you need help and help others when they need it.
  5. Actively discuss the progress of the project.

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. Meet or coordinate to decide upon the task for the day.
  2. Set up more impromptu meetings if required.
  3. In meetings share thoughts openly with each other.
  4. In meetings, make sure everyone has their voice heard.

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. Have a text conversation with teammates in the group chat.
  2. Have a live face to face conversation with teammates.
  3. Come up with a new plan moving forward to address the issues.
  4. Reach out to TAs
  5. Reach out to Irene, Firas

N.B. Please do not hesitate to expand beyond 5 steps if needed.

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. Remember we are all in this together and trying our best.
  2. Take a break/walk.
  3. Don't take your frustrations out on fellow teammates.
  4. Be kind to eachother.
  5. Use a voting system to make team decisions.

Deadlines

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

  1. Finish the project at least 3 days before the official deadline as approvals would be required.
  2. Use the 2 days before the deadline for correcting the comments received.
  3. If you know you're struggling to reach a particular deadline, reach out to your teammates so that they can help you.

...etc...

*N.B.

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 [Name of chosen Git Workflow] workflow, and the following conventions (e.g., master branch protection, at least X reviews before a pull request, at least N days before the deadline etc...):

  1. Only add new features in your own branch.
  2. Test all of you code before issuing a pull request.
  3. Issue all pull requests at least 2 days before the deadline.
  4. At least one team member must review before accepting a pull request.
  5. Master branch must have no errors at all times (keep it protected, don't merge bad code!)