CS3281 Schedule

The info given below is from the previous round, as a reference only. Major changes are highly unlikely, however.

The schedule for future weeks is tentative, given as a reference only. The prof will finalize the details of a week near to the start of the week, although major changes are highly unlikely.

Week 1 [15th Jan]

Todo

  • Update GitHub profile: As most of your work will be submitted via GitHub, you are encouraged to update your GitHub profile with your full or partial name.
  • Add your info to the repo nus-cs3281/2025 [⏰ Deadline: Friday]. You will be given write permission to the repo by Monday.
  • Set up the dev environment of your project in your Computer. Follow instructions provided by the project for new contributors.
  • Join nusossprojects slack channel when you receive the invitation. As our projects use slack for chats, please keep slack running (and notifications enabled) during periods in which you are actively involved in our projects (or check slack at least once a day).

Monday

  • Lecture: CS3281 Course Intro

Saturday (Code Sprint)

  • The code sprint is an opportunity for you to spend an extended amount of time on the project so that you get a solid start to the coding activities. Some project mentors may be available during this time for you to discuss project related matters with them.
  • Agenda
    • 10-11am: A common Zoom session for students and mentors to introduce themselves. Try to join from a private location where you can use the webcam and appear without a mask. The Zoom link will be posted in Canvas.
    • 11am onwards: Separate briefings for each project, on Zoom, led by mentors. e.g., technical overview, on-boarding, etc. Will be recorded in case some students are interested to learn a 2nd project. The Zoom links will be provided by the mentors on the day.
    • Afternoon: Students do tasks indicated by mentors earlier and consult mentors if needed.
    • 4-5.30pm: Prof to meet with each team separately for a short debriefing. Mentors need not join.
      Use the same Zoom link used for the intro session.

Week 2 [22nd Jan]

Monday

  • Lecture: Product demos, project-specific discussions
  • Demo the product created by your project.
    • MarkBind, RepoSense, TEAMMATES: ~20 minutes each
      CATcher: 10-15 minutes (also include WATcher in the demo)
    • The main objective is to learn/explain the product from the user's POV. Focus on giving an overview of the product from the user's POV, and limit to highlights of the features if there are many features (i.e., no need to do a comprehensive demo of every little feature). No need (but preferred) for every team member to take part either. Decide among yourselves who will demo which feature.
  • Guidelines for the demos:
    • Everyone must contribute, but it is not necessary to (although good to) have everyone speaks/presents during the demo.
    • Showcase some of the more impressive features in a reasonable order. There is no need to demo all features.
    • The aim is to impress the audience about the product, not to educate them on how to use it (it is not a 'how-to' tutorial)
    • Plan, and follow, a specific path that you know well and has been proven to work (the so called golden path), rather than plan to 'wing it'.
    • Use good demo data that puts the product in a good light, rather than use trivial demo data (aaa, test123 etc.).
    • Some parts may be covered using pre-recorded screencasts, to save time (e.g., parts that takes a longer time to demo in real-time).

Week 3 [29th Jan]

Monday

  • Lecture: Project-specific discussions

Keep records of your work

As you learn the codebase, investigate issues, learn related tools etc., try to get them recorded somewhere. Some options:

  • record in your 'knowledge' page e.g., a tool you learned
  • post it an issue in the issue tracker e.g., investigating the applicability of a tool to the project
  • an update to project documentation e.g., a solution you found to a problem that happens in the dev environment

Reasons: It increases the visibility of your work. Those records can be useful references to you and others.

Week 4 [5th Feb]

Monday

  • Lecture: Project-specific discussions

Sunday

Week 5 [12th Feb]

Todo

  • If you haven't started already, this is a good time to start getting at least one peer-review from classmates before requesting reviews from a senior developer.
    • You can request a review from a peer directly or you can post a 'call for reviewers' in the respective chat channels.
    • You can get early inputs from senior devs if necessary, e.g., you are not sure about the overall direction of the PR, you want to know the rationale for the current code, etc.
  • You can also help to manage new/external contributors e.g., answer their questions, review their PRs etc. Even if their question is directed at a senior dev or the prof, you can jump in and answer if you know the answer.

Monday

  • Project-specific discussions (public holiday)

Sunday

  • Keep updating the the progress page and the knowledge page on a weekly basis, as was done in the previous week. These pages are used in grading.
  • ⏰ PR to update these csv config files if all your internal project work is not captured in the dashboard. More info about the file format can be found here.

Don't worry if your RepoSense graph doesn't have as many ramps as others. Data shown on the RepoSense report are not directly comparable across projects or even within a project, as different projects have different commit rates and the nature of one dev's work may be very different from another. The RepoSense report is just a means for conveniently accessing your work in one page, and also a means of stress testing RepoSense.

Week 6 [19th Feb]

Monday

  • Lecture: Project-specific discussions

Recess

Week 7 [4th Mar]

By the end of this semester, we expect you to,

  1. deliver substantial value to the project, which may be through developing a fairly big feature (working solo or with others) or doing a bunch of tasks in a specific area,
  2. more importantly, to gain expertise in a substantial part of the codebase (while being fairly familiar with the rest).

If you can't work out a plan that achieves the above, you can seek guidance from the seniors and/or the prof as well.

  • ⏰ by Friday
    • Peer evaluations
  • ⏰ by Sunday
    • Update the progress page

Monday

  • Lecture: Project-specific discussions

Week 8 [11th Mar]

Monday

  • Lecture: Project-specific discussions

Week 9 [18th Mar]

Monday

  • Lecture: Project-specific discussions

Week 10 [25th Mar]

As you are now entering the managing phase, get more involved in management activities of the project.

Monday

  • Lecture: Project-specific discussions

Week 11 [1st Apr]

Help to maintain a healthy supply of beginner-friendly issues: If you encounter small non-urgent issues (so called 'low hanging fruits'), it is best to leave them for future new contributors, because we expect several new contributors to join the project during the upcoming summer.

In fact, go the extra mile to create such issues when you can, as a good supply of such beginner-friendly issues is an essential asset for an OSS project.

Todo

  • Plan to finish ongoing (and new) PRs by end of week 12, with one week to spare. If PRs are stalling due to lack of reviews from mentors, feel free to nag.

Monday

  • Lecture: Project-specific discussions

Week 12 [8th Apr]

Monday

  • Lecture: Project-specific discussions

Week 13 [15th Apr]

Monday

  • Lecture
    • Project specific discussions

As we are now reaching the end of the semester:

  • Wrap up any ongoing PRs soon. Only merged work can be counted for grading.
  • Update your knowledge and progress pages. Those will be used in grading.

Soft deadline: end of week 13; hard deadline: end of reading week

Reading week, exam period

  • Ensure the progress/knowledge pages are up-to-date latest by the end of the first week in the exam period.

Work done after the semester

  • The work done after the semester is over can earn credit when taking CS3282 later.
    • Any value addition towards the course (e.g., PR reviews, mentoring, development work, etc.) can be used for the above.
    • The work done prior to CS3282 start date can count up to 40% of the course load i.e., at least 60% of the course work needs to be done during the semester itself.
    • Keep good records of the work done so that they can be included in CS3282 work later when you take the course.
  • While keeping in touch with the project during the intervening period is not compulsory, it is strongly encouraged as it would help you to deepen your expertise in the project. The more expertise you have in the project, the better you will be able to do project management and mentoring tasks included in the CS3282 workload.
  • See here for more info on CS3282 workload.