Skip to content

working-in-a-group.md

Latest commit

 

History

History
28 lines (18 loc) · 2.6 KB

working-in-a-group.md

File metadata and controls

28 lines (18 loc) · 2.6 KB

Working in a group

Before you begin a group project, agree your ways of working. This will help you to work together effectively and efficiently. Read the ways of working below and discuss them with your team. If you have extra conditions, agree them now.

Suggested Ways of Working

We recommend following these Ways of Working (at a minimum, feel free to add more) as we have found them to be effective across many project teams at CYF:

  • Create a temporary Slack channel for your team. Use this channel and your class time for communication about the project management and the product development.
  • Each team member must understand the requirements of a ticket before moving it from the Backlog to Ready. Make use of your class time to discuss the tickets as a team.
  • Decide whether you are going to work on tickets individually or as a pair. You may work faster on your own but may understand more about the codebase as a pair. Remember that you are expected to be able to explain how parts of the codebase that you did not write work.
  • Set up a GitHub repo (see below) that every team member has access to.
  • Each feature must be reviewed by another member of your team. Set a branch protection rule (see below) on your main branch to enforce this.
  • Each team member can pick up a new ticket only when their old ticket is in review. Work on one thing at a time.

Set up the repo

  • One person should create a new repo in their own GitHub account and name it Checkpoint-Sprint-SPRINT_NUMBER-Project
  • That person should add the other team members as collaborators to the repo.
  • Now someone else should make a copy of the example planner and link it to your project repo.

On the branch protection settings

Set the following:

Require a pull request before merging. When this is enabled, all commits must be made to a non-protected branch and submitted via a pull request before they can be merged into a branch that matches this rule.

Require approvals: 1. When this is enabled, pull requests targeting a matching branch require a number of approvals and no changes requested before they can be merged.