- Conceptualize v1.2
- Draft the UG
- Refine the product design
- Set up the project repo
- Get familiar with the code base
indicates an individual task (i.e., each team member has to do the task, graded individually) while indicates a team task (some or all members may do the work; graded for the whole team).
tP tasks progress is graded. Completing individual and team tasks are considered for grading the project management component of your project grade.
Most aspects of 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 waste 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.
PR review comments matter! Remember to do proper PR reviews throughout the tP, at least for non-trivial changes, as the quality and quantity of PR review comments you have given to peers affect your tP marks (under the project management aspect).
1 Conceptualize v1.2
- Based on your user stories selected previously, conceptualize the product in terms of how it will look like at v1.2 in the form of a feature list.
Note down the feature list in your online project notes document.
FAQ: How many features should we put in v1.2?
A: Aim for the smallest set of features the product cannot do without. Even a most basic version of those features is enough. After completing that feature set, you can add more if there is time left.
2 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 v1.2.
- We recommend that you follow the AB3 User Guide in terms of structure and format.
- As this is a draft only and the final version will be in a different format altogether (i.e., in Markdown format), don't waste time in formatting, copy editing etc. You can also limit this to just the 'Features' section only and omit the other sections.
While the UG draft need not be 'polished', it should be detailed enough to tell the user how to use the product features in concern. - IMPORTANT:
- Specify the precise/full command syntax for the CLI commands that you will deliver at v1.2. i.e., we want you to know exactly what you plan to deliver at v1.2 -- while it is fine to change this plan later, it is still important to have a plan first.
- Include all features that will be available in v1.2. There is no need to include features that will be delivered beyond v1.2.
- Consider including some UI mock-ups too (they can be hand-drawn or created using a tool such as PowerPoint, PlantUML, Figma, etc. -- they can be very low-fidelity mock-ups, as they are meant to be temporary).
- Submission [one person per team]: Save the draft UG as a PDF file, name it
{team-id}.pdfe.g.,CS2103-T09-2.pdf, and upload to Canvas.
Recommended: Divide 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.
If you are not sure what we mean by 'enhancements/features each person would be adding' mentioned above, see the panel below for our recommendation on how to divide the tP work:
3 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.
4 Set up the project repo
- Set up the team org, the team repo, and individual forks as explained below:
5 Get familiar with the code base
FAQ: Is this a team task or an individual task?
A: It's an individual task (note the icon above), to be done by each member, as we want every member to be familiar with the code base.
- Ideally, you should do this task in this week (i.e., midnight before the week 6 tutorial), but you may take an extra week (i.e., by the week 7 tutorial) to finish them without penalty.
- Do the following tutorials to get familiar with the codebase
- Tutorial 1 - Tracing a Command Execution Path
- We recommend that you put in a sincere effort into this tutorial because tracing through the code of an unfamiliar code base is an important skill that you will not be able to learn/practice it later in the project as the code will no longer be 'unfamiliar' to you later.
- Submission [optional]: Post an issue in your team's repo with the title
Tutorial: tracing code. In the description, add a 2-3 screenshots you took while at various points of the tutorial. You may close the issue soon after.
- Tutorial 2 - 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. You may close the PR soon after. - FAQ: Do we have to write/update test cases too?
A: Not a strict requirement, but given the purpose of this tutorial is to learn the code base, it's ideal if you do. It will familiarize you with the existing testing infrastructure. Otherwise you can run into difficulties when you are writing test cases for your own features later.
- Tutorial 3 - Removing a field from an entity
- This tutorial is optional to do, but at least give it a quick read.
- Submission: not required.
- Tutorial 1 - Tracing a Command Execution Path
- 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 when merging code in your tP: