iP:
A-Gradle
, A-CheckStyle
, Level-10
, A-Varargs
tP:
...
icon on the top right corner of the previous description and choose Edit
(how?) the description of the iP PR you created earlier so that it contains the following GFMD elements:
If you wish, you may write the PR description to be very similar to the example given above -- as the goal here is to demonstrate your mastery of the GFMD syntax (not ad writing skills).
Please wait till Mon, Aug 30th 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.
Step 1 Note these additional guidelines:
Comment
(i.e., not Approve
or Request changes
)Step 2 Do the first PR review as follows.
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.
If the allocated PR is not suitable, use the same strategy as before to find an alternative PR to review.
Links → iP Code Dashboard
item 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.A-Gradle
, A-CheckStyle
, Level-10
, A-Varargs
master
branch only when ready (if you push incomplete features into the master
branch, 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.
As we are still at the early stages of identifying a problem to solve, do not think of the product (i.e., the solution) yet. That is, do not discuss the product features, UI, command format, and implementation details, etc. unless they are pertinent to the decision of the project direction.