- Attend the practical exam dry run During the lecture on Fri, Apr 1st counted for participation
- Start fixing PED bugs Before the tutorial
- Polish the deliverables
- Draft the PPP
-
Prepare for the demo rehearsal - Try PDF conversions early
- Ensure the code is RepoSense-compatible
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):
1 Attend the practical exam dry run During the lecture on Fri, Apr 1st counted for participation
- See info in the panel below:
2 Start fixing PED bugs Before the tutorial
- Triage the bugs you received in the PE-D, by following the procedure given below:
- Note what is allowed in this milestone:
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).
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)
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.
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 is 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 features or feature flaws (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.Q: The tester has categorized a PE-D issue as a feature-flaw but we think it is a bug. How to proceed?
A: The category chosen by the tester is immaterial. You have to choose the correct category and proceed accordingly.Q: How to distinguish between bugs and feature modifications?
A: A bug is when the actual behavior differs from the advertised behavior (i.e., the behavior stated in the UG) due to an error in the code.
Describing a feature in the UG without implementing it is a UG bug. The remedy is to remove the feature from the UG.
If the behavior difference is because some parts of the feature is not implemented yet, the feature is incomplete (i.e., not a bug). The remedy is to remove the feature (if it is not usable in the current form) or update the UG to match the current version of the feature.Q: What if an issue is related to a behavior not specifically stated in the UG?
A: In that case, we go by the reasonable 'correct' behavior that one expects. For example, the UG might not specify what happens if a user typed an extra space after the first keyword of the command (e.g.,mark[SPACE]1vsmark[SPACE][SPACE]1) in which case the reasonable correct behavior is to ignore the extra space.
- Start fixing bugs that you selected to fix in this iteration. 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.
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):
- Minimal: all PE-D bugs have been triaged, bugs to be fixed in the current iteration have been chosen, and assigned to relevant team members.
- Recommended: all (or almost all) the PE-D that you have chosen to fix have been fixed already.
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
- Must fix: 6 bugs (fixed: 5)
- Good to fix: 8 bugs (fixed: 1)
3 Polish the deliverables
- Do more extensive testing yourselves. The panel below contains guidelines your peers will use when determining bugs in the final product -- knowing them might be useful in preventing such bugs in your product in the first place.
- 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).
- Consider increasing test coverage by adding more tests if it is lower than the level you would like it to be. Take note of our expectation on test code (given in the panel below).
- After you have sufficient code coverage, fix remaining code quality problems and bring up the quality to your target level.
Refactoring code does not violate a feature freeze (as refactoring doesn't change the behavior). Still, it is not advisable to (but you are allowed to) do major refactorings this close to a major release.
4 Draft the PPP
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.
- Fill up the skeletal Project Portfolio Page (PPP) you created earlier with a draft version of content.
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).
5 Prepare for the demo rehearsal
6 Try PDF conversions early
- Take note of the following project constraint:
- Take note of the following info about the PDF conversion, appearing in next week's project tasks. Particularly, note the suggestion to try PDF conversions early.
7 Ensure the code is RepoSense-compatible
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:
- Go to the tp Code Dashboard. Click on the
</>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.
- More info on how to make the code RepoSense compatible:
- Go to the tp Code Dashboard. Click on the