This site is from a past semester! The current version will be here when the new semester starts.

iP: Week 3iP: Week 5


iP: Week 4

  1. Create a PR to the upstream repo Mon, Aug 30th 2359
  2. Add Increments: Level-4, A-TextUiTesting, A-CodeQuality
  3. Get ready to review PRs before the tutorial
  4. Review some peer PRs during the tutorial counted for participation

1 Create a PR to the upstream repo Mon, Aug 30th 2359

  • Create a pull request (PR) from your fork to the upstream repo. Note the following:
    • Create the PR from the master branch of your fork to the master branch of the upstream repo (https://github.com/nus-cs2113-AY2122S1/ip)
    • Set the PR name as [{Your name}] iP e.g., [John Doe] iP If you are reluctant to give full name, you may give the first half of your name only.
      You may leave the description as empty.
    • If you created the PR correctly, it should appear in the list of PRs here.
    • Steps for creating a PR is given in this textbook topic (steps 5 onwards):

The PR will update automatically to reflect your latest code every time you push code to your fork. As a result, it provides a convenient way for us to access the current state of all your iP code from one location.

2 Add Increments: Level-4, A-TextUiTesting, A-CodeQuality

Duke Level-4: ToDo, Event, Deadline
Duke A-TextUiTesting: Automated Text UI Testing optional
Duke A-CodeQuality: Improve Code Quality

3 Get ready to review PRs before the tutorial

  • Do the following to prepare for the PR review exercise you will be doing in the coming tutorial.
    • Learn how to review PRs:

4 Review some peer PRs during the tutorial counted for participation

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., not Approve or Request 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 sections on Naming and Readability 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.


iP: Week 3iP: Week 5