Project Management:

• One team member: Set up the team org and team repo for your team if you haven't done that already.
  • Set up auto-publishing of docs

Organization setup

The instructions below are for setting up a GitHub organization for your team.

You can create your GitHub account after receiving your team ID. Here are the instructions (please follow the organization/repo name format closely because we use scripts to download your code. If the names are not as expected, our scripts will not work):

• One team member (e.g. team leader) should create an organization with the following details:
• Organization name : BASEJAN2018-TEAM_ID. e.g.  BASEJAN2018-W09-B3
• Plan:  Open Source ($0/month)
• After that, the same person can add members to the organization:
• Create a team called developers to your organization.
• Add your team members to the developers team.

Repo setup

Only one team member:

1. Fork Address Book Level 4 to your team org.
2. Rename the forked repo as main. This repo is to be used as the repo for your project.
3. Ensure your team members have the desired level of access to your team repo

All team members:

1. Fork the main repo (created above) to your personal GitHub account.
2. Clone the fork to your Computer.
3. Set it up as an Intellij project (follow the instructions in the Developer Guide carefully).

Note that some of our download scripts depend on the following folder paths. Please do not alter those paths in your project.

• /src/main
• /src/test
• /docs

• All members: Set up your own forks of the team repo, so that you can submit PRs to your team repo using the forking workflow.

Before you do any coding for the project, please ensure you have set the Git username correctly (see panel below for more details) in all Computers you use for coding.

Documentation:

Recommended procedure for updating docs:

1. Divide among yourselves who will update which parts of the document(s).
2. Update the team repo by following the forking workflow.
3. One member: create a PR from your team repo master branch to [nus-cs2113-BASE/addressbook-level4] master branch. PR name: [v1.x][Team ID] Product Name e.g., [v1.x][T09-B2] Contact List Pro.  As you merge code to your team repo's master branch, this PR will auto-update to reflect how much your team's product has progressed (that's why we use v1.x instead of v1.0 in the PR title). In the PR description mention the other team members so that they get notified when the tutor adds comments to the PR.

Project Management → Revision Control →

Forking Flow

In the forking workflow, the 'official' version of the software is kept in a remote repo designated as the 'main repo'. All team members fork the main repo create pull requests from their fork to the main repo.

To illustrate how the workflow goes, let’s assume Jean wants to fix a bug in the code. Here are the steps:

1. Jean creates a separate branch in her local repo and fixes the bug in that branch.
2. Jean pushes the branch to her fork.
3. Jean creates a pull request from that branch in her fork to the main repo.
4. Other members review Jean’s pull request.
5. If reviewers suggested any changes, Jean updates the PR accordingly.
6. When reviewers are satisfied with the PR, one of the members (usually the team lead or a designated 'maintainer' of the main repo) merges the PR, which brings Jean’s code to the main repo.
7. Other members, realizing there is new code in the upstream repo, sync their forks with the new upstream repo (i.e. the main repo). This is done by pulling the new code to their own local repo and pushing the updated code to their own fork.

• A detailed explanation of the Forking Workflow - From Atlassian

• About Us page:
  This page is used for module admin purposes. Please follow the format closely to avoid penalties.
  • Replace info of SE-EDU developers with info of your team, including a suitable photo as described here.
  • Including the name/photo of the supervisor/lecturer is optional.
  • The photo of a team member should be doc/images/githbub_username_in_lower_case.png e.g. docs/images/damithc.png.

• The purpose of the profile photo is for the teaching team to identify you. Therefore, you should choose a recent individual photo showing your face clearly. Some examples can be seen in the 'Teaching team' page. Given below are some examples of good and bad profile photos.
  

• If you are uncomfortable posting your photo due to security reasons, you can post a lower resolution image so that it is hard for someone to misuse that image for fraudulent purposes. If you are concerned about privacy, you can request permission to omit your photo from the page by writing to prof.

• Indicate the different roles played and responsibilities held by each team member. You can reassign these roles and responsibilities later in the project, if necessary.

• README.adoc page: Update it to match your project.

  • Add a UI mockup of your intended final product.
    Note that the image of the UI should be docs/images/Ui.png so that it can be downloaded by our scripts.
  • The original README.adoc file (which doubles as the landing page of your project website) is written to read like the introduction to an SE learning/teaching resource. You should restructure this page to look like the home page of a real product (not a school project) targeting real users  e.g. remove references to addressbook-level3, Learning Outcomes etc. mention target users, add a marketing blurb etc. On a related note, also remove Learning Outcomes link and related pages.
  • Acknowledge the original source of the code i.e. AddressBook-Level4 project created by SE-EDU initiative at https://github.com/se-edu/

• User Guide: Start moving the content from your User Guide (draft created in previous weeks) into the User Guide page in your repository.

• Developer Guide: Similar to the User Guide, start moving the content from your Developer Guide (draft created in previous weeks) into the Developer Guide page in your team repository.

Product:

• Each member can attempt to do a local-impact change to the code base.

  Objective: To familiarize yourself with at least one component the code.

  Description: Divide the components among yourselves. Each member can do some small enhancements to their component(s) to learn the code of that component. Some suggested enhancements are given in the AddressBook-Level4 developer guide.

  Submission: Create PRs from your own fork to your team repo. Get it merged by following your team's workflow.

  ❗️ Before you start coding, please read our reuse policy given below, in particular, how to give credit when you reuse code from Internet or classmates: