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:
- use this channel for general team communication
- individual participation in this and other channels may be used towards each member's grade
Channel names must be short and consistent. For example, if a team is named octopus, their main channel might be called team-octopus
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.
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.
View a video overview of setting up a Task Board on GitHub.
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.