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

Week 4 [Fri, Feb 2nd] - Project

iP:

Create a PR to the upstream repo Mon, Feb 5th 2359
Add Increments: Level-4, A-TextUiTesting, A-CodeQuality
Get ready to review PRs before the tutorial
Review some peer PRs during the tutorial

tP:

Start weekly project meetings
Start a collaborative doc to take project notes before the tutorial
Decide on an overall project direction (user profile, problem addressed) before the tutorial

iP

1 Create a PR to the upstream repo Mon, Feb 5th 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-AY2324S2/ip)
- Set the PR name as [{Your full/partial name or your Github username}] iP
  e.g., [Richard Mathews Chee] iP or [Rich ... hee] iP or [TheRichMat] iP
  Note that the PR name will be publicly visible.
  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:

Read the Best practices for reviewing PRs @SE-EDU/guides. You are expected to follow all of them.

4 Review some peer PRs during the tutorial

This task is worth 2x2=4 participation 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.
- Make sure you add 'review comments' (not regular comments) as only those are counted for participation. See step 4 in the panel above to find how to add 'review comments'.
- 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.
- Give comment on coding standard related issues only.
  Review comments don't always have to be about problems in the code. Other things you can do:
  - complement the author on not making a common mistake
  - ask questions
  - suggest alternatives
- 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.

tP: Set direction

Timely completion of the weekly tP tasks can improve the project management component of your tP grade.

1 Start weekly project meetings

We recommend you start weekly project meetings now. You can use the meeting to do tP tasks, but also help each other do iP tasks. On a related note, it is also acceptable to discuss weekly Canvas quiz (if any) together with team members as you do the quiz i.e., discuss and decide the answer collectively, but you should not give away your answers to someone who was not part of that discussion.

2 Start a collaborative doc to take project notes before the tutorial

Keep project notes in easy-to-use collaborative docs (Recommended: use a GoogleDoc). This document will be checked by the instructors at various points.
Remember to choose a tool that allow public view access e.g., GoogleDoc can be shared via a public link so that the document can be viewed by others. You'll be asked to submit this link to us in the next week.
Make sure all you current and future project notes (if split into in multiple documents) are reachable via links given in this document and are viewable by the public.

3 Decide on an overall project direction (user profile, problem addressed) before the tutorial

Decide the target user profile, and problem addressed, as described in the panels below (tip: you can use your first project meeting for this):

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 user profile or the problem addressed.

You can use the button in a panel to open it as a new tab (it can be expanded in-place too). This feature is available only for panels containing another full page of the website (i.e., not available if the panel contains an extract of a page).

Admin tP: Expectations

Admin tP: Constraints

Pick a CLI-friendly product domain: Given Recommendation-CLI-First and Constraint-Typing-Preferred mentioned in the panels above, it makes sense to pick a product domain that is more suitable for CLI interactions i.e., a product that deals with easy-to-type textual data, needs a small number of data fields, and each data field is short. For example, a blog editor is an unsuitable product domain because it also deals with non-text data (e.g., images, videos) and some data fields are quite long (i.e., paragraphs of text). Similarly, keeping track of extensive employee records may be an unsuitable domain if there are many data fields per employee.

Submission: Submit via TEAMMATES.
- Details to submit:
  1. Product name (plain text only) e.g., ClientContactsPro
  2. Target user profile (plain text only) e.g., freelance event photographers
  3. Value proposition i.e., what problem does the product solve? (plain text paragraph, no more than 50 words) e.g., provide fast access to client contact details, optimized for users who prefer a CLI
    This is not a list of features -- you should not think about exact features yet.
  4. Link to the project notes document: This should be an online document/page (not a folder) -- e.g., a GoogleDoc (not a Google Drive location) -- that is publicly accessible. If your project notes are in multiple locations/files, this one document should contain the link to the other documents with guidance on which link is for what.
- You'll receive an email from TEAMMATES with the submission link. Only one member needs to submit on behalf of the team. All members can view/update the submission.