Working With Your Team

You should have received comments on your project assignment under the GitHub issues your team created. However, before you begin working on your assigned project and start writing code, there are several things you should know about the expected workflow for collaboration among your team members.

The Git Workflow

Your project ideas all require substantial modifications and additions to the existing IDLE code base. Your work (including planning, implementing, and testing) should be incremental in nature. We expect the project workflow for each team to be highly collaborative, and the primary space for collaboration would be your GitHub repository.

Your group will operate very much like a small team in an industry setting, which means that, at a minimum, the following things are expected of you–

I. Appropriate usage of git branches

Most of the time, the development work will be split between your group members, each being responsible for a small part of the overall implementation. This means that each developer will be working on their own branch. No one should be writing code directly in the master branch!

In the end, your whole project work should be presented in a feature branch, e.g. a branch named feature-git-integration if your project is integrating Git into IDLE. Throughout the course of your project, your development branches will be merged into this feature branch. (This also means that no one should be pushing code directly into the feature branch either without creating a pull request!)

II. Creating and reviewing pull requests

Just like how you have been doing for individual projects, each developer on your team will be creating periodic pull requests whenever a small task is completed.

Continuing the example of the Git integration project, if after the initial meeting, you are given a first task of creating an empty status bar UI element, while your other teammates work on integrating the Git APIs, then you would create a new development branch from the feature branch named add-basic-status-bar. Once you are done with the implementation of this (hopefully) simple task, you will create a pull request to merge your add-basic-status-bar branch into the feature branch feature-git-integration.

There are many conventions for naming git branches. Your team can choose whatever naming convention you like best.

Instead of the course staff reviewing your pull requests, you and your teammates will be reviewing each other’s PRs. We will discuss pull requests and code reviews in more detail in future lectures. Once your pull request for that small task has been thoroughly tested and reviewd by all team members with all questions/concerns resolved, the pull request may be merged, and you can consider that task completed.

III. Using Github Projects

Please use Github Projects and Issues to track each task that your team needs to complete. We will be reviewing the Github Project for each team as part of the grade for “Project Management”. We should see a task board with numerous tasks/issues assigned to team members and organized lists (i.e., columns) to track progress.

On Incremental Development

Ideally, each week your team should be meeting to discuss the task distribution for that week. Break down the project work into smaller parts that can be carried out in parallel – huge tasks only beget procrastination and misery, and the act of breaking down your requirements also helps you with better understanding how to approach the overall implementation.

If all goes well, each of your group members would be working in parallel on some small parts of the project every week, at the of which you will all review each other’s pull requests for the completed tasks. The goal of these code reviews, as we will discuss in later lectures, is less about offering critique on others’ work (although constructive criticism should always be welcomed), but more about understanding what others have written – if you don’t understand a piece of code in the pull request you are reviewing, ask the author! With the scope of these projects, everyone should understand all the code being added to the code base, including what is written by other team members.