when setting the v1.4 deadline in GitHub milestones, remember that the v1.4 submission deadline is Week 13 Monday 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.
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 PE-D). 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:
fixing bugs (but not feature flaws) -- we use a very restrictive definition of 'bugs' for the feature freeze; to avoid violating the feature freeze unintentionally, be sure to check the FAQs below before you do any fixes/tweaks.
improving code quality
Not allowed in v1.4:
any UI changes (even purely cosmetic enhancements e.g., alignments, style changes are not allowed).
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:
Q1: How to differentiate between bugs and feature changes?
Q2: Will we be penalized for feature flaws not fixed during the feature freeze?
Q3: What if an issue is related to a behavior not specifically stated in the UG?
Q4: What if a feature is mentioned in the UG but not available fully in the product?
Q5: Can we tweak validity checks for a user input, or error/exception handling?
Q6: Can we tweak error/help messages (or other text shown to the user)?
Q7: Can we tweak case-sensitivity of a feature?
Q8: A UI text gets truncated (or overflows) for certain inputs (or certain Windows sizes); can we fix them?
Q9: Can we tweak the command format?
Q10: The tester has categorized a PE-D issue as a feature-flaw but we think it is a bug (or vice versa). How to proceed?
As before, you may split this milestone into smaller iterations if you wish e.g.,
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
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.
This task is time-sensitive. If done later than the deadline, it will not be counted as 'done' (i.e., no grace period). Reason: This is 'an early draft'; if done late, it is the 'final version' already.
Convert the PPP to a PDF to see if the page-count is within expectations (the PDF version can be longer than what you would expect by looking at the HTML version).
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.
FAQ: What if someone took over a feature from another team member?