tP: v1.3
Coming soon
.docs/index.md
): Update to look like a real product (rather than a project for learning SE) if you haven't done so already. In particular, update the Ui.png
to match the current product ( tips).v1.3.1
Ensure your code is i.e., RepoSense can detect your code as yoursRepoSense-compatible and the code it attributes to you is indeed the code written by you, as explained below:
</>
icon against your name and verify that the lines attributed to you (i.e., lines marked as green) reflects your code contribution correctly. This is important because some aspects of your project grade (e.g., code quality) will be graded based on those lines.Smoke-test CATcher
3
participation points. Please do it before the weekly deadline.Some background: As you know, our i.e., Practical ExamPE includes peer-testing tP products under exam conditions. In the past, we used GitHub as the platform for that -- which was not optimal (e.g., it was hard to ensure the compulsory labels have been applied). As a remedy, some ex-students have been developing an app called CAT stands for Crowd-sourced Anonymous TestingCATcher that we'll be using for the PE this semester.
This week, we would like you to smoke-test the CATcher app to ensure it can run in your computer.
Deliver v1.3
Update user docs
Coming soon
.docs/index.md
): Update to look like a real product (rather than a project for learning SE) if you haven't done so already. In particular, update the Ui.png
to match the current product ( tips).Demo v1.3
v1.2
,
v1.3
.v1.3 features demo
.Add sequence diagrams to the developer guide
Deliver v1.3
Release as a jar file
v1.3.1
Wrap up v1.3
Review others' DG
Decide which of the given team(s) to review:
Go to the PR of the team(s) you have chosen to review.
Review the Design
and the Implementation
sections w.r.t possible DG bugs (given further down); add your observations as comments.
Is this format correct? Should it be ... instead?
) rather than directives (e.g., Change this to ...
).Attend the practical exam dry run
Polish the product as per peer-testing results
Allowed in the v1.4 milestone:
fixing bugs
improving documentation
purely cosmetic enhancements e.g., alignments, style changes
improving code quality
improving tests
removing features
Not allowed in v1.4: adding features or doing major changes to existing features.
The goal of freezing features in the pre-release iteration is to subject the features to at least one round of intensive non-dev testing before they are released to the users. In a real project, minor or critical changes might be allowed even near a deadline -- but here, we do not allow any feature changes because it can start us on a slippery slope and many "is this change allowed?" queries. Therefore, v1.4 should not have any features that was not already tested in the PE-D).
FAQs:
Fix bugs that were reported during the PE-D. Don't rely on PE-D alone to find bugs. Also keep in mind that bug fixing can cause regressions which you'll have to catch and fix.
Do more extensive testing yourselves.
Update documentation to match the product. In particular, finalize the content of the DG early and check it thoroughly for bugs (reason: unlike the UG, the DG did not get tested in the PE dry run).
v1.4
, v1.4b
, ...Draft the PPP
Prepare for the demo rehearsal
Prepare final deliverables
Double-check RepoSense compatibility
Do final polish-ups
Submit deliverables
Submissions:
To convert the UG/DG/PPP into PDF format, go to the generated page in your project's github.io site and use this technique to save as a pdf file. Using other techniques can result in poor quality resolution (will be considered a bug) and unnecessarily large files.
Ensure hyperlinks in the pdf files work. Your UG/DG/PPP will be evaluated using PDF files during the PE. Broken/non-working hyperlinks in the PDF files will be considered as bugs and will count against your project score. Again, use the conversion technique given above to ensure links in the PDF files work.
Try the PDF conversion early. If you do it at the last minute, you may not have time to fix any problems in the generated PDF files (such problems are more common than you think).
The icon indicates team submissions. Only one person need to submit on behalf of the team but we recommend that others help verify the submission is in order
We will not accept requests to limit late penalties of team submissions to one person even if the delay was one person's fault. That is, the responsibility (and the penalty) for team submissions are to be shared by the whole team rather than burden one person with it.
The icon indicates individual submissions. When uploading files to LumiNUS, please upload your individual files yourself. Reason: Penalties related to submission time/format are calculated automatically based on the uploader's identity.
v1.4
or v1.4b
.[team ID][product name].jar
e.g. [CS2103-T09-2][Contacts Plus].jar@@author
annotations after the deadline will be considered a later submission). Note that the quality of the code attributed to you accounts for a significant component of your final score, graded individually.[TEAM_ID][product Name]UG.pdf
e.g.[CS2103-T09-2][Contacts Plus]UG.pdf[TEAM_ID][product Name]DG.pdf
e.g. [CS2103-T09-2][Contacts Plus]DG.pdf[TEAM_ID][Your full Name as Given in LumiNUS]PPP.pdf
e.g.[CS2103-T09-2][Leow Wai Kit, John]PPP.pdf-
in place of /
if your name has it e.g., Ravi s/o Veegan
→ Ravi s-o Veegan
(reason: Windows does not allow /
in file names)github.io
Ui.png
, AboutUs.md
etc.) on GitHub. Ensure the website is auto-published.Wrap up the milestone
Submit the demo video
Prepare for the practical exam
Attend the practical exam
v1.2
,
v1.3
.v1.3 features demo
.