tP:
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.
Remind yourself of the project grading criteria and our policy on reuse (e.g., how to give credit for reused code):
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/changing 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 behaviors that were not already tested in the PE-D).
FAQs:
Q: Can we add a missing validity check for a user input?
A: Yes, but only if its absence causes the software to mis-behave (i.e., it's omission can be considered a bug).
Q: Can we tweak the command format?
A: No, as this would be considered changing the design of a feature.
Q: Testers have reported missing feature (or suggested feature tweaks). Can we add/tweak those features?
A: No, as that goes against the spirit of having a feature freeze. Most teams receive such suggestions from testers as we allow feature suggestions in PE-D (but they are not allowed in the PE). You can use those suggestions when you envision future versions of the product (i.e., beyond v1.4 -- to improve your product design skills. But for now, focus on fixing bugs, and perfecting other aspects such as testing, documentation, code quality.
Also note that given there's a feature freeze in v1.4, some lower-priority features can be argued as out-of-scope if there were other higher priority features that took up the available time in previous versions. Every team has to draw the line somewhere as there wasn't a lot of time to implement features.
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 bug triaging progress: 100%
- Must fix: 6 bugs (fixed: 5)
- Good to fix: 8 bugs (fixed: 1)
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 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.