CS2103/T Website - Admin: tP: mid-v1.1 [week 6]

Set up the project repo
Get familiar with the code base
Conceptualize v2.0
Draft the UG
Refine the product design

indicates an individual milestone (i.e., each team member has to do their part of the milestone, graded individually) while indicates a team milestone (some or all members may do the work; graded for the whole team).

Milestone progress is graded. Be reminded that reaching individual and team milestones are considered for grading the project management component of your project grade.

Most aspects project progress are tracked using automated scripts. Please follow our instructions closely or else the script will not be able to detect your progress. We prefer not to spend admin resources processing requests for partial credit for work that did not follow the instructions precisely, unless the progress was not detected due to a bug in the script.

Milestone requirements are cumulative. The recommended progress for the mid-milestone is an implicit requirement for the actual milestone unless a milestone requirement overrides a mid-milestone requirement e.g., mid-milestone requires a document to be in a temp format while the actual milestone requires it to be in the proper format. Similarly, a requirement for milestone n is also an implicit requirement for milestone n+1 unless n+1 overrides the n requirement. This means if you miss some requirement at milestone n, you should try to achieve it before milestone n+1 or else it could be noted again as a 'missed requirement' at milestone n+1.

1 Set up the project repo

Set up the team org and the team repo as explained below:

2 Get familiar with the code base

Do the following tutorials to get familiar with the codebase
- Tutorial 1 - Tracing a Command Execution Path
- Tutorial 2 - Removing a field from an entity
  - If you are an experienced programmer, you can remove a different field than the one given in the tutorial.
  - Submission: Do your changes in a branch named tutorial-removing-field and push to your fork.
- Tutorial 3 - Adding a new Command
  - If you are an experienced programmer, you can add a different command than the one given in the tutorial.
  - Submission: Do your changes in a branch named tutorial-adding-command, push to your fork, and create a PR from your fork to your team's repo.
Ideally, you should do the above tutorials by week 6 (i.e., midnight before the tutorial), but you may take an extra week (i.e., by the week 7 tutorial) to finish them without penalty.
The PRs created for tutorials need not be merged, unless the changes are actually in line with your project idea.
For reference, given below is the workflow you should follow use to merge code in your tP:

3 Conceptualize v2.0

Based on your user story categorization in the previous week, given module requirements/constraints for the project, and the current state of the product, select which user stories you are likely to include in v2.0.
Conceptualize the product in terms of how it will look like at v2.0.

4 Draft the UG

Draft a user guide in a convenient medium (e.g., a GoogleDoc) to describe what the product would be like when it is at v2.0.
- We recommend that you follow the existing AB3 User Guide in terms of structure and format.
- As this is a very rough draft and the final version will be in a different format altogether (i.e., in asciidoc format), don't waste time in formatting, copy editing etc. It is fine as long as the tutor can get a rough idea of the features from this draft. You can also do just the 'Features' section and omit the other parts.
- Do try to come up with concrete command syntax for the CLI commands that you will deliver at the end of the semester.
- Consider including some UI mock-ups too (they can be hand-drawn or created using a tool such as PowerPoint, PlantUML or Balsamiq).
- Submission: Save the draft UG as a PDF file, name it {team-id}.pdf e.g., CS2103T-W09-1.pdf, and upload to LumiNUS.

Recommended: Divide documentation work (in the User Guide and the Developer Guide) among team members equally; preferably based on enhancements/features each person would be adding e.g., If you are the person planing to add a feature X, you should be the person to describe the feature X in the User Guide and in the Developer Guide.

Reason: In the final project evaluation your documentation skills will be graded based on sections of the User/Developer Guide you have written.

5 Refine the product design

Review the UG to ensure the features written by each member fit together to form a cohesive product. Note that cohesiveness of the product can affect the grading of the product design aspect.