tP:
v1.4
when setting the v1.4 deadline in GitHub milestones, remember that the v1.4 submission deadline is early in Week 13 for everyone (does not vary by tutorial day). Set your own milestone deadline accordingly, or else our grading scripts will flag it as an 'unsuitable' deadline.
Remind yourself of the project grading criteria and our policy on reuse (e.g., how to give credit for reused code):
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 other words, avoiding behavior changes unless they are strictly necessary, so that we minimize the possibility of introducing more bugs.
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 behaviors that were not already tested in the ). Hence, the feature freeze comes into effect at the point you released the JAR file that was used for the PE-D.
While the info below provides you what to do and what not to do in v1.4 specific cases, the important thing is to understand and follow the spirit of the feature freeze (i.e., do not change features further; correct unintentional errors only).
Allowed in the v1.4 milestone:
Not allowed in v1.4:
Using 'Planned Enhancements' DG section to counter known feature flaws: Given you are not allowed to fix feature flaws in v1.4, we allow you to optionally add a section named Appendix: Planned Enhancements
to the end of the DG. More details in the panel below:
FAQs on what is allowed during the feature freeze:
As before, you may split this milestone into smaller iterations if you wish e.g., v1.4
, v1.4b
, ...
Expectations at mid-v1.4 (i.e., by the tutorial date):
On the tutorial day, one member should post a message in your team's MS-Teams channel (i.e., the one inside the MS-Teams used for tutorials) stating if PE-D bug triaging is done, how many bugs were selected as 'must fix' and 'good to fix' in v1.4 and how many of them have been done already. Remember to tag the tutor in that post. Note that this post will be counted as a team progress deliverable e.g.,
Our team's mid-v1.4 progress:
- PE-D issues received: 47
- Unique bugs: 14
- Not allowed to fix in v1.4: 3
- Must fix: 6 (fixed: 5)
- Good to fix: 4 (fixed: 1)
- Won't fix / invalid: 1
If you have 0
for the category Not allowed to fix in v1.4
when doing the above, we urge you to take another harder look at constraints imposed by the feature freeze, to confirm you are not violating the feature freeze inadvertently (which can cost you marks later). It is common for some of the PE-D bug reports to be related to enhancements rather than bugs that are allowed to be fixed in v1.4. Therefore, it is 'unusual' to have 0 bugs for that category.
PE-D bug titles will be prefixed with tester ID e.g., ([PE-D][Tester A] UG does not load
) to make it easy for you to bugs reported by each tester.
Furthermore, tester ID mapping (i.e., who is Tester A, Tester B, etc.) will be sent to you via email within 1 day after the PE-D.
Ensure your code is 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.