CS2113/T - Admin: tP week 7: Get ready for iterations

Set up the project repo during the tutorial
Plan the next iteration

1 Set up the project repo during the tutorial

Set up the team org, the team repo, and individual forks as explained below:

tP Team Organization Setup

Please follow the organization/repo name format precisely or else our grading scripts will not be able to detect your work.

(/) Only one team member:

After receiving your team ID, one team member should do the following steps:

Create a GitHub organization with the following details:
- Organization name (all UPPER CASE) : AY2021S2-TEAM_ID. e.g. AY2021S2-CS2113T-W12-1, AY2021S2-CS2113-T09-2
- Plan: Open Source ($0/month)
- This organization belongs to: My personal account
Add members to the organization:
- Create a team called developers to your organization.
- Add your team members to the developers team.

tP Team Repo Setup

(/) Only one team member:

The tP project template given to you is a variation of the iP repo you used for the iP, but with some important differences. Please follow instructions carefully, rather than follow what you remember from the iP.

Fork the https://github.com/nus-cs2113-AY2021S2/tp repo to your team org.
- This repo (let's call it the team repo) is to be used as the repo for your project.
- Please do not rename the fork Reason: our grading scripts rely on the repo name.
Enable the issue tracker.
Enable GitHub Actions: Go to the Actions tab and enable workflows by clicking the button. That will enable the GitHub Actions that are already included in the repo you forked.
Enable GitHub Pages: Go to the Settings tab and enable GitHub Pages for the master branch /docs folder (similar to how you did it in the iP).
Remember to choose a theme too by clicking the button (that will create a commit in your repo that is needed in a later step.
After a few minutes, confirm your tP website is available in the corresponding github.io URL.
Add members. Ensure your team members have the desired level of access to your team repo.
Recommended: Give admin access to 1-2 members and write access to others.
Create a team PR for us to track your project progress: i.e., create a PR from your team repo master branch to [nus-cs2113-AY2021S2/tp] master branch. PR name: [Team ID] Product Name e.g., [CS2113-T09-2] InsureList. 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.
Please fill in these details as specified because they are used by our grading scripts.
- PR subject: the name of your product e.g., [CS2113-T09-2] InsureList
- Description: a 1-2 sentence overview (plain text only, no formatting or links) of your project indicating the target user and the value proposition e.g., InsureList helps insurance agents manage detail of their clients. It is optimized for CLI users so that frequent tasks can be done faster by typing in commands.

tP Individual Fork Setup

(, , , ...) Every team member:

Watch the tp repo (created above) i.e., go to the repo and click on the button to subscribe to activities of the repo.
Fork the tp repo to your personal GitHub account.
Please do not rename the fork Reason: our grading scripts rely on the repo name.
Clone the fork to your computer.
Set up the developer environment in your computer by following the the README carefully as the steps are different from the iP.

Do not alter these paths in your project as our grading scripts depend on them.

src/main/java
src/test/java
docs

2 Plan the next iteration

Plan the next iteration. As you know, you should follow the breadth-first iterative process. Therefore, first you must decide what functionalities should be in the product if you had only two weeks to implement it. You have done that already when you chose user stories for v1.0, translated that to features, and even drafted the UG based on those features. You can tweak that plan further at this point if you wish, given that you now have some idea of how fast the team can work when using the prescribed workflow.
- Aim to produce a working MVP at the end of this iteration even if the functionalities are not polished (polishing can be done in a later iteration).
- If possible, break the iteration into two increments i.e., aim to produce an even simpler but working version after one week.
- Avoid depth-first implementations: "I'll do the back-end part of feature X in this iteration" is not acceptable as that is not in the spirit of iterative development. Remember, we are pretending this to be the last iteration; why would you implement the back-end part of a feature in the last iteration?
  It is OK to add simpler versions of bigger features, but not OK to add partial features that can't be used yet.
Divide the work among the team members i.e., the work required for the current iteration.
Reflect the above plan in the issue tracker by assigning the corresponding issues (create new issues if necessary) to yourself and to the corresponding milestone. For example, the user story pertaining to the increment show a place holder for photo, showing a generic default image should be assigned to Jake and to milestone v1.0
Optionally, you can define a mid-v1.0 milestone to keep track of things to be done within the first half of the milestone.