Every individual and group must complete the following kickoff process to have the tools setup to allow them to collaborate effectively on team projects.
Each team will decide, using whatever decision-making process they prefer, on which two members will fill the initial roles of Scrum Master and Product Owner.
- all team members, including Scrum Master and Product Owner, are also Developers - everyone is expected to do the design and code work in every sprint.
- these roles must shift every Sprint, so each team member should fill each role at least once.
- each team must announce which team members are Scrum Master and Product Owner at the start of each Sprint
Discord is each team's primary communication tool. Each member's communications and contributions within Discord are tracked and may be used towards grading.
Each team must have at least one Discord channel where the professor, and any course assistants, graders, and tutors are also invited to be members:
Channel names must be short and consistent. For example, if a team is named octopus, their main channel should be called team-octopus
- use this channel for general team communication
- individual participation in this and other channels may be used towards each member's grade
Communications within private channels or on communications systems where the stakeholders are not present are not visible to stakeholders and therefore will not be considered analyzing the engagement of any individual or of the team as a whole.
In order to allow your managers to track your individual contribution to the project, it is imperative that you use the same username for both git on your local computer, where you will be making commits, and GitHub, where you will be doing pull requests.
To set your git username locally... change 'monalisa' in the example to your own username:
git config --global user.name "monalisa"To ensure your GitHub username is used for all online activity, leave your account's Name field blank:
Once you've made a few contributions both locally and on GitHub, you can verify that the user names are the same in the git logs:
git logHere is the full recipe:
- Look at your git logs: run
git log. Hit the space bar to scroll through the logs and hitqto quit when you're done. Check your username as it shows up in the logs... is it always correct for every log entry and does it match what you see in your grading emails? If so, you're done. If not, continue... - Figure out your GitHub username: go to your GitHub settings (https://github.com/settings/profile) and remove anything in the
Namefield, then save the changes. Note your username at the top-left of the page once you save - this is your GitHub username... you knew that. - Figure out your git username: run
git config user.nameto see your git username on your local machine - this is yourgitusername. - If your usernames don't match, then run this:
git config --global user.name "monalisa", wheremonalisais replaced with your GitHub username. Now your usernames match!
GitHub is each team's primary resource for version control, project planning, issue tracking, and project documentation. Each member's contributions within GitHub are tracked and used towards grading.
Each team member must understand that their contributions are only visible if they commit work using their own git/GitHub account.
GitHub repositories have been created for each team and are in the control of the team. There are several key files that all repositories must have properly set up.
Every project must have a README.md that automatically renders on the project's main repository page with basic details of the project, including:
- a description of project, including the Product Vision Statement
- the core team members, including links to their GitHub accounts and any other web presence they have
- a short history of how the project came to be and information about how to contribute to the project (i.e. a link to the CONTRIBUTING.md document)
- instructions for building and testing the project (update with that information once the project reaches that stage)
- links to any additional Markdown documents or web pages that may be relevant reading about the project
- anything else you think is important to communicate to people viewing the project
Each team must collaboratively draft a CONTRIBUTING.md - a Markdown document exclusively dedicated to how others might contribute to this project. This document is essentially a contract agreed-upon by all developers and contributors, and includes at a minimum:
Details on the team's values and process:
- the Team Norms
- the Git workflow that the team follows
- a detailed description of the rules of contributing and any considerations or how and what to contribute
- instructions for setting up the local development environment in order to work on this project
- instructions for building and testing the project (update with that information once the project reaches that stage)
This documents allows potential contributors, whether in the open source community or in a private organization, to see the project's rules and processes for contributions. It should be well-formatted with clear headings and subheadings.
GitHub provides a link to this document automatically to any user who creates a Pull Request on this project.
Each repository must have a .gitignore file that informs git not to track platform code, 3rd party library code, and other common development artifacts that are not your own code. It is also imperative to not track files that contain sensitive information, such as usernames/passwords to a database, or files containing users' personal information.
Use this example .gitignore file for Node.js-based web apps as the baseline for your .gitignore file.
Each team must create a set of labels for using within GitHub's Issues tracker. Labels allow you to tag an issue in a particular category or context for easy filtering later.
Begin by creating the following labels. Once you begin development, every Issue in GitHub's Issues tracker must be assigned one of these labels:
user story- to be used for all user storiestask- to be used for all tasksspike- to be used for all spikes.
Feel free to create other labels that are useful to your team.
Each team must have a set of Milestones to represent each Sprint within GitHub's Issues tracker:
Sprint 0Sprint 1Sprint 2Sprint 3Sprint 4
What to include in each Milestone's settings:
- a description of the big picture idea of what the Sprint is aiming to achieve
- the due date for the Sprint, as indicated by the due date of the Stakeholder Demos on the course schedule
Once a particular sprint has begun, all issues representing tasks that have been decided to be addressed within that sprint must be assigned to the proper Milestone representing that sprint.
Each team must create a Task Board for each of the four Sprints following these setup instructions (these use the "Classic" type of Task Boards available on GitHub).
View a video overview of setting up a Task Board on GitHub.
When in development, teams are expected to follow the feature branch workflow, where all changes are made in branches, peer reviews are done via pull requests, and approved changes are merged into the main branch, which is always in a deployable state.
Team members must make these feature branches in the shared team repository, not in a fork or other copy of the repository.
Each team member must clone their team's GitHub repository onto their own local machine and push any changes they make back to GitHub at regular inteverals - at least once between Standup meetings.
Each team must have an initial Product Backlog - a set of User Stories that together define the product requirements - based on their understanding of the project so far. This will evolve as teams work on the project, but try to think through and write User Stories for as many features as you can imagine wanting to include in the project.
Each item in the Product Backlog must be added as an Issue to GitHub's Issue tracker.
View a video overview of setting up a Product Backlog on GitHub.
Make sure you understand how GitHub's Issue tracker works and attach the user-story label to all Issues that represent User Stories.