Working With Your Team
You have received feedback on your project proposals via your Gradescope submission. Additionally, please remember to create your team project GitHub repository where you will be implementing your project (click here for more information).
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 main 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 your assignments, 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 at least on of the 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.
IV. Reflections
Each week, you will complete a brief reflection on your progress, both as a group (completed collaboratively) and individually (completed by each member). These reflections help both the teaching staff and your team track progress, identify challenges, and ensure steady advancement throughout the project.
You can find questions for your weekly reflections1 here:
The reflections are going to be due each Wednesday (as shown in the course schedule). To submit your reflections please create an issue in your group project repository called Week [Number] Reflection (where [Number] is the number of the week) and add both group and individual reflections answers to the issue.
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.