- Review some peer PRs counted for participation
- Learn from others (optional)
- Add Increments as branches:
A-Gradle,A-CheckStyle,Level-10,A-Varargs
1 Review some peer PRs counted for participation
Please wait till Mon, Feb 1st to start this task, to give others a few extra days to create the PR if they haven't done so yet.
This task is worth 2x2=4 participtaion points.
- Learn how you should review PRs in this task:
Step 1 Note these additional guidelines:
- Read the Best practices for reviewing PRs @SE-EDU/guides. You are expected to follow all of them.
- If the PR has received some review comments already, feel free to confirm/complement/question those comments in your review. Also, look for things the previous reviewers may have missed.
- At the end of the review, choose
Comment(i.e., notApproveorRequest changes)
Step 2 Do the first PR review as follows.
- Comment on coding standard violations only.
- The review allocation is given in the panel below.
If the student you have been allocated to review has not created a PR (or the PR has a trivial amount of code), you can review the Backup PR to review provided in the allocation table. Failing both, review another PR allocated to another student in your own tutorial but not in your team.
Tip for future reference: GitHub allows you to filter PRs/Issues using various criteria such as author:AuthorUsername (example -- see the filters text box in the target page).
Alternatively, you can use PR labels (if any) to filter PRs/Issues.
FAQ: How many comments should I add? Answer: Depends on the code being reviewed but we expect most PRs would warrant at least 4-5 comments. If the PR is huge, you can stop when you think you've put in a fair amount of time on the job (~15 minutes) and added enough comments for the PR author to receive some value.
- Step 3 Do the second PR review as follows.
- Comment on other code quality guidelines (see the section Naming in this textbook chapter) you have learned so far. It's optional to comment on coding standard violations in this PR review.
- The review allocation is given in the panel below.
If the allocated PR is not suitable, use the same strategy as before to find an alternative PR to review.
- Step 4 [When you receive reviews for your own PR] Respond to comments received. You are recommended to (but not obliged to) respond to comments received from peers, especially if the PR reviewer asked you for more info. As mentioned in these guidelines, do not get into arguments with PR reviewers/authors.
2 Learn from others (optional)
- You can use the iP Code Dashboard to view others' iP code, using the
Links → iP Code Dashboarditem in the top navigation menu. Click on the </> icon corresponding to a student name to see the code written by that person. We encourage you to read others’ code and learn from them. If you adopt solutions from others (also encouraged), please follow our reuse policy.
3 Add Increments as branches: A-Gradle, A-CheckStyle, Level-10, A-Varargs
- Do each enhancement in a separate branch and merge to the
masterbranch only when ready (if you push incomplete features into themasterbranch, it can confuse others reviewing your PR). There is no need to do the increments as parallel branches though i.e., you can do one increment and merge that branch before starting on the next one.
If you have completed any of them in previous weeks, just add the corresponding tag (no need to create a branch).
- Note that you no longer need to keep the text-based UI after adding a GUI. Similarly, there is no need to use the I/O redirection style automated testing anymore (that technique is suited for text UIs only).