P1: Project Setup

P1: Project Setup #

Deadline: Jan 24, 11:59pm Eastern Time

Once your team has been formed, you should create a private GitHub repository for your project. You will also initialize several important documents for your project: readme, time log, and team contract.

Create GitHub Project #

Create one single GitHub repository that will host all the code and documentation for your project.

  • Your repository visibility should remain private for the duration of this course.
  • Your repository must be named with a prefix teamXX-, where XX is your team number (which may range from 01 to 30). The part after the prefix can be a short name representing your team / app. For example, if you’re team 7, your repository name should be something like team07-awesome-app.
  • The repository should be placed under the username of one of your team members.
  • Invite all other team members to the repository as collaborators.
  • Invite the course staff’s account, wat-cs446, as a collaborator.

Readme #

Create a file called README.md at the root directory of your repository. Include the following information at the beginning of the file:

  • A short name for your team / project
  • Your team number
  • Each team member’s information:
    • Name
    • Quest ID (e.g., p2nie)
    • 8-digit student ID
    • GitHub username(s)

As you project progresses, you can update this file to include more information about your project, e.g., project description, links to notes, download/installation instructions, etc.

Time Log #

Create a file called timelog.csv (in CSV format) at the root directory of your repository. This file will be used to track the time spent by each team member on the project.

The file can be initialized with the row header (replace NameX with the actual names of team members):

date,Name1,Name2,Name3,Name4,Name5,Name6,task

Each row should record: on day X, Y number of hours was spent on task Z. A task can be collaborated by multiple team members. For example:

2025-01-06,0.5,0,0,0,0,0,setup GitHub repo
2025-01-07,1,1,1,1,1,1,first team meeting

It is very important to keep this file up-to-date. We will periodically check the data in this file to verify if you are making good progress on the project. It will also be used to determine the individual effort scaling factor.

Team Contract #

You should meet as a team to discuss how you plan to collaborate during this term. Your discussion should be recorded in a file called team-contract.md at the root directory of your repository.

The exact content is decided by the team, but the contract typically addresses:

  • Team leadership and communication
  • Team meeting expectations
  • Team & individual expectations
  • Managing team challenges and conflict
  • Other considerations

Defining team roles #

It is useful to determine team roles at the start of a project, to help guide the team’s work. Roles can include:

  1. Team Lead: This is the project leader, NOT the technical leader for the project. This person is responsible for keeping the team on track and ensuring that the project is completed on time. They do this by ensuring that the requirements are defined accurately, that the team is tracking work properly, and that the team is meeting its goals for each deliverable. They often define the agenda for the team meeting, take minutes and ensure that the team is following the team contract.

  2. Technical Lead: This person is responsible for ensuring that the technical aspects of the project are completed correctly. They are responsible for ensuring that the team is following best practices, that the code is complete and follows course guidelines. In the way that the team lead helps manage the project, the technical leader helps manage the code contributions of the team. They often review code, help team members debug, and ensure that code is reviewed and merged properly.

  3. Design Lead: Teams (at least in this course) may have a Front-End Design Lead, and a Back-End Design Lead, each of which is responsible for the design and delivery of a core part of the product.

Note that these roles are NOT prescriptive. They are meant to guide the team in their work. The team should be flexible and adapt to the needs of the project. It’s normal for someone to wear multiple hats e.g. design lead for the front-end, but also handling packaging (because they may have done that before).

This means that, for example:

  • Team leads still write code. Managing the project is not a full-time job.
  • Technical leads can still take meeting minutes and write code. They are not just code reviewers.
  • Design leads can still help with other parts of the project outside of their immediate area of responsibility.

No single person is “the boss” of the project, and significant decisions should be made with the input of the entire team.

Team meetings #

Team meetings are an essential part of any project. They provide an opportunity for team members to discuss progress, share ideas, and make decisions. Communication is most effective when it’s both written and oral, so it’s important to have regular team meetings.

However, meetings are expensive in terms of time and resources. They are most effective when you have a clear goal for the meeting. For each meeting:

  • You should have an agenda: what are you going to discuss? This can be as simple as a set of bullet points for discussion, or as detailed as a design for a feature where you require input. A team lead will typically prepare and circulate the agenda ahead of time.
  • Everyone should come to the meeting prepared to discuss topics on the agenda. This means reading any required materials, watching lecture videos etc.
  • The project lead should keep the team organized around the agenda and ensure that the meeting stays on track. Make sure you accomplish what you intended to accomplish.
  • Someone should be designated to take notes during the meeting. These notes should be circulated to the team after the meeting.

Conflict management #

Conflict is a natural part of work on a team. It can arise from personality differences, differences in opinion, or differences in work style. Conflict can be beneficial to a team, as it can lead to better decision-making and more creative solutions. However, if not managed properly, it can also lead to stress and demotivation.

There are five main approaches to handling conflict:

  • Avoiding or Withdrawing: Individuals in conflict retreat from the situation in order to avoid an actual or potential disagreement. This approach can cause the conflict to fester and then escalate at a later time.
  • Competing or Forcing: In this approach, conflict is viewed as a win–lose situation in which the value placed on winning the conflict is higher than the value placed on the relationship between the individuals. This approach to handling conflict can result in resentment and deterioration of the work climate.
  • Accommodating or Smoothing: This approach emphasizes finding areas of agreement within the conflict and minimizes addressing differences. Topics that may cause hurt feelings are not discussed. Although this approach may make a conflict situation livable, it does not resolve the issue.
  • Compromising: Team members search for an intermediate position. The solution may not be the optimal one.
  • Collaborating, Confronting, or Problem Solving: Team members confront the issue directly, with a constructive attitude, and look for a win–win outcome. They place high value on both the outcome and the relationship between the individuals. For this approach to work, it is necessary to have a healthy project environment.

In a particular conflict situation, you will tend to have a preference for one style over the others depending on the dynamic of the team and your personality.

In a team environment, we recommend team-friendly strategies: accommodating, compromising or collaborating. This is in-part why we enforce regular team meetings, and decision-making by consensus; it helps ensure that everyone’s opinion is considered and that decisions are made in a way that is fair to everyone.

The end goal of a conflict resolution process is to explore different options and comes up with the best (or mutually acceptable) idea.

Members should view conflicts within the organization as conflicts between allies, not opponents. The goal is for the team to win, not for one person to win over another.

Team contract template #

Here is a template that you can follow to create your team contract. Feel free to modify it to fit your team’s needs.

# Team Contract (Team XX)

## Roles

- XXX is our team lead, and is responsible for coordinating the project.
- XXX is responsible for merging code into main branch and producing product releases.
- XXX is responsible for the front-end design and features.
- XXX is responsible for the database and backend design.

## Communication and Meetings

- Our team will use Discord/Slack/Teams group chat to communicate project-related matters.
- Our team will meet every Mon and Wed during class.
- All members will attend these meetings or notify the team in advance of anticipated absences. We all agree that absences should be rare.
- All group members will come to the meetings prepared by:
  - reading the assigned material (as much as possible), and
  - coming with ideas pretaining to the tasks and decisions to be made.
- Members will not work on other assignments during meetings and will be engaged.
- Decisions can be made during meetings even some members are absent.
- Each member will take turns listening as well as talking, and active listening will be a strategy for all group discussions.

- XXX will post the agenda for the week in our group chat before Mon class.
- XXX will take notes during all meetings and post them on GitHub Wiki within 1 day.

## Conduct

- Everyone agrees to the code of conduct outlined in the course policies.

How to Submit #

On Learn, submit the link to your GitHub repository.

We will check if the repository and files are properly initialized according to the instructions above by the deadline. No extra submission needed.