This site is from a past semester! The current version will be here when the new semester starts.
CS2103/T 2020 Jan-Apr
Schedule
  • Full Timeline
  • Week 1 [Jan 13]
  • Week 2 [Jan 20]
  • Week 3 [Jan 27]
  • Week 4 [Feb 3]
  • Week 5 [Feb 10]
  • Week 6 [Feb 17]
  • Week 7 [Mar 2]
  • Week 8 [Mar 9]
  • Week 9 [Mar 16]
  • Week 10 [Mar 23]
  • Week 11 [Mar 30]
  • Week 12 [Apr 6]
  • Week 13 [Apr 13]
  • Textbook
  • Admin Info
    • Links
  • Report Bugs
  • Forum
  • Instructors
  • Announcements
  • File Submissions
  • Tutorial Schedule
  • Java Coding Standard
  • Participation Marks List
    •  Individual Project (iP):
  • Individual Project Info
  • Duke Upstream Repo
  • iP Code Dashboard
  • iP Showcase
    •  Team Project (tP):
  • Team Project Info
  • Team IDs
  • Addressbook-level3
  • Addressbook-level 1,2,4
  • tP Code Dashboard
  • tP Showcase
    •

    • Week 7 [Mar 2] - Tutorial

    1 Exercise on Requirements: PR Tracker

    • Divide the team into sub-team A and sub-team B, 2-3 members each.
    • 7-8 minutes Write the answers to the following questions on the white-board.

    Question adapted from a past exam paper.

    Pull Request Tracker (PRT) is a desktop application meant to help CS2103 tutors deal with GitHub PRs more efficiently (compared to the GitHub Web interface). For example, it will help tutors find and review PRs from their mentees easily. It will help the managers of the module (e.g., professor, head TA) to easily keep track of how tutors are dealing with mentee PRs. PRT will communicate with GitHub using the GitHub API.

    Sub-team A:

    • Write 1 must-have and 1 nice-to-have user stories, covering user types tutor and manager.
    • Write at least 1 Non-Functional RequirementsNFRs, related to performance/scalability and/or usability.
    • Give at least 1 terms worth recording in the glossary.

    Sub-team B:

    • Complete the following use case. Give at least one extension. Note that the tutor should give comments in the order of PR size (i.e., give comments to smaller PRs first). Assume the following use cases exists already: U1. Sort PRs by a criterion, U2. Add comments to a PR

    System: PRT
    Use Case: U3. Add comments to mentee PRs
    Actor: ...
    Precondition: ...

    ...
    • 7-8 minutes Discuss the answers with the whole team and the tutor

    2 Review Requirements of a Peer Team

    • Find the team you have been allocated to discuss in the panel below and click on the link to locate their team PR.

    In each tutorial:

    Team Discuss PR of Backup team to discuss
    1 2 3
    2 1 4
    3 4 1
    4 3 2
    • Go to the PR.
    • In another Browser tab, open their Developer Guide page in their website (i.e., the html version, not the adoc version).
    • 7-8 minutes Read the following sections in the DB and add review comments in the PR of areas to improve and doubts.
      If the DG does not have enough content for you to review, you can review the backup team (see the third column in the allocation panel). If even the backup team is not suitable, choose any random teams having tutorials in the same day and not in the same tutorial as you.
    • To be done collectively with sub-team members.
    • Add the review comment in the correct place of the code.
    • Choose the Start a review option rather than Add single comment.
    • Each person can do their own review, but coordinate with sub-team members to avoid duplicating the same point.
    • Phrase your comments as question/doubts (e.g., Is this format correct? Should it be ... instead?) rather than directives (e.g., Change this to ...).
    • Do not finalize the review at this stage. Just keep adding comments.

    Sub-team A: Review use cases, w.r.t. the possible bugs are given below.

    Sub-team B: review user stores, NFRs, glossary, w.r.t. the possible bugs are given below.

    • 7-8 minutes Discuss your comments/observations/doubts with the tutor and other team members to confirm the comments you entered are correct.
    • 5 minutes Update your review comments if necessary, based on the discussion you just had. After that, you can submit the review.
      After adding comments, you may want to unsubscribe from the PR to avoid getting GitHub alerts from that PR in the future.