CS3281 Schedule

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 [13th 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: A 'dev-experiments' session
    • Objectives: for you to get to know team members (and possibly, some mentors), and help each other set up (and get familiar with) the dev environment.
    • Structure:
      1. Starts with a brief course intro (by prof)
      2. Sit together with team members
      3. Get to know team members
      4. Help team members set up dev environment
      5. Start doing some experimental changes to code, with the aim of getting familiar with the code base

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 2 [20th Jan]

Monday

  • Lecture: A 'user-experiments' session
    • Brief product intro (by prof)
    • Experiment with the product as a user i.e., try to use the product, and stretch its limits, simulate use cases etc.
      You can follow the suggested 'user experiments' in this page.
    • Show your 'dev experiments' (done last week) and 'user experiments' to prof.
      If you have queries about the product (e.g., motivations behind some features), this is a good time to clarify them.
  • Record your dev/user experiments in your progress.md, and keep updating the knowledge.md as you learn new things.

Week 3 [27th Jan]

Monday

  • Lecture: Product demos
  • Demo the product created by your project.
    • MarkBind, RepoSense, TEAMMATES: ~15-20 minutes each
    • 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, and take part in the demo. Also include a self-intro (name, year, major, something interesting about yourself).
    • 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 4 [3rd Feb]

Monday

  • Lecture: Project-specific discussions

Sunday

Week 5 [10th 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 [17th Feb]

Monday

  • Lecture: Project-specific discussions

Recess

Week 7 [3rd 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 [10th Mar]

Monday

  • Lecture: Project-specific discussions

Week 9 [17th Mar]

Monday

  • Lecture: Project-specific discussions

Week 10 [24th 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 [31st Mar]

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 [7th Apr]

Monday

  • Lecture: Project-specific discussions

Week 13 [14th 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.