CS3281 : Thematic Systems Projects I

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

CS3281 semester can be divided into three stages: Stage 1: Learning, Stage 2: Contributing, Stage 3: Managing.

Lectures

MON 1200-1400 in COM1-02-12

Projects

Following NUS-OSS projects will be used this semester.

  • MarkBind
  • RepoSense
  • CATcher
  • SE-EDU (only as a secondary project)
  • TEAMMATES

See the Projects/Mentors page for more info on the current focus of each project and the list of mentors.

Stage 1: Learning

Duration: Week 1 - 3 (3 weeks)

Objective: Learn the project’s codebase, workflows, tools, etc. under the guidance of the current developers.

Things to do

  • Set up the project and complete any orientation tasks specified by the project.
  • Start submitting PRs.

Recommendations

  • When choosing issues to fix, start with simpler issues and progressively move into more complex issues. Choose issues strategically so that your knowledge of the codebase expands naturally and incrementally (instead of picking unrelated issues at random).
  • Pay attention to instructions provided e.g. Developer guides, troubleshooting guides, etc. Following those instructions will reduce the chances of encountering problems. When you encounter problems, try to solve yourself before asking for help.
  • Your PRs will be reviewed by the project's dev team. You are expected to learn from the review comments and improve the quality of your work as you go. You will not score high if you keep repeating the same mistake even after being corrected by the reviewer multiple times.
  • Focus on learning how things are done in the project; hold back your suggestions on ‘how to do things better’ until stage 3 (i.e. until you have a more in-depth idea about the project).

Stage 2: Contributing

You can spend upto 40% of your CS3281 effort on one or more secondary NUS-OSS projects. SE-EDU projects can be selected as a secondary project too.

Duration: Week 4 - 9 (6 weeks)

Objective: Contribute to the project based on the project’s priorities and you role in the project.

Things to do

  • Decide which areas (i.e. aspects, features, tools, etc. relevant to the project) of the project you want to be responsible for. Ideally, there should be at least two persons for each area (one primary, one secondary).
  • Continue to contribute PRs, particularly those related to your areas.
  • Get your PRs reviewed by peers (based on area division mentioned in point 1 above) before submitting them to dev team’s review.

Recommendations

  • Pick areas that have synergy with your interests but also note that your value to the project will be higher when you volunteer for ‘unpopular’ areas.
  • The quality of your peer reviews will be as important to your grade as the quality of your code. If the PR is found to have problems later, those problems will count against both the author and the peer reviewer.
  • Don’t always pick the same peer reviewer. The more peer reviewers you use, the more you can learn from peers.

Stage 3: Managing

Objective: Learn how to play a more senior role in a big project

Duration: Week 10 - 13 (4 weeks)

Things to do

  • Continue to submit PRs. In some cases you will be given permission to merge PRs yourself.
  • Get involved in other tasks done by senior developers: e.g. refining the project workflow, making toolstack choices, mentoring new developers, triaging new issues/PRs, creating releases, dealing with users, etc.

Recommendations

  • Take this as an opportunity to show how qualified you are for the ‘next level’. Those who perform well in this stage will be offered senior positions in the project in the future.

Stage 4: After the semester is over

This stage is optional but highly recommended.

Objective: To keep in touch with the project, accumulate credit for CS3282

Duration: Until you start CS3282

Things to do

  • Continue to help manage the project (e.g., help to guide in contributors).
    Minimally, help maintain the issue tracker and the PR workflow (e.g., take turns to reply to new issues, review PRs etc.)
  • You are welcome to submit PRs too.

Team structure

Will be based on the project chosen. Could be subdivided into smaller teams within the project based on the specific areas you work in.

Grading

As a general principle, try to do good work and become better software engineers as you do course work, and good grades will follow. Given the small class size, it will be easy to detect attempts to 'game the system' or 'optimize for grades over learning' and such behavior will not earn you high grades. In other words, follow the spirit (rather than the letter) of the grading scheme.

  • Consistency [5%]: this component is an incentive for you to spread the work across the semester. To earn full marks, you should meet both these criteria.

    • Committed code (in your PRs) in at least 10 weeks
    • Merged PRs in at least 5 weeks. For this criteria, PR merges can be credited to future weeks but not past weeks. e.g. if you happen to merge two PRs in a week, one can be counted for that week and the other for a future week (but not for a past week).
  • Learning [5%]: this component is an incentive for you to learn the relevant tools and technologies well.

  • Achievements [80%]:

    • Measures the quality, depth, and quantity of your work.
      Your goal should be to become as highly valued to the project as possible, not to do as much work as possible. i.e., quality and depth is more important than quantity or speed.
    • At around weeks 4 and 8, prof will give you some feedback on how you are progressing in the course.
  • Professional conduct and teamwork [5+5=10%]:

    • Measures how good your conduct was,
      • as a professional [5%]: e.g., punctuality, reliability, participation, etc.
      • as a team member [5%]: e.g., willing to contribute to common tasks, work as a team rather than work in isolation, give due considerations to the needs of the project rather than consider what is good for own grades only.
    • Graded based on peer evaluations and instructor observations.

Expertise Areas

While this is not a graded deliverable (it used to be; we made it non-graded recently to reduce the workload), you are encouraged to choose your CS3281&2 work in a way that gives you an 'expertise' in a few areas.

Objective: Gain in-depth knowledge of a few specific areas so that you are considered an expert of those areas compared to your peers.

Just one or two semesters is certainly not enough to become an ‘expert’ of something. Consider these courses as just the initial steps in the journey of becoming an expert. Our expectations are,

  • By the end of the two courses, you know your chosen expertise areas better than your peers to the extent that you can teach those peers interesting and useful things from those areas.
  • Based on your current trajectory, assuming you continue to improve your knowledge in that area, your knowledge in that area is among the top 5% of your cohort by the time you graduate.
  • Recommended: select an area strongly related to SE.

Things you can do

  1. Consider picking one from each of the three below.

    • An Aspect: Various aspects of an SE project e.g. Testing, CI, Scalability, Requirements, Security, Performance, ...
    • A Language: e.g. Java, C#, Go, Python, Ruby, Kotlin, Elixir, JavaScript, HTML, CSS, ...
    • A Domain: Any other technical topic relevant to SE that you want to claim as your interest/expert area e.g Search Engine Optimization, Regular Expressions
  2. Learn more about them yourself. While you do that, produce evidence of your knowledge. E.g. blog posts, stackoverflow questions/answers

  3. Share interesting and useful bits of your knowledge with the class by giving short talks, to be done in CS3282 later (refer Lightning Talks deliverables explained below)

Pre-Course Preparations

  • Bigger code bases take time to learn. You can set up the project and start contributing before the semester starts. Even prior work can be counted for course grading later.

  • Dive deeper into the primary programming language of your intended project. Writing code for big projects require a lot more than a basic knowledge of the programming language. If you are weak in any of the main programming languages used in the project, start learning them now.

    Project Languages Tools
    MarkBind JavaScript, CSS Node.js, NunJucks
    RepoSense Java, CSS, HTML, JavaScript Jade, Gradle, Cypress
    CATcher TypeScript, CSS, HTML, Python Electron
    SE-EDU Java, CSS Gradle, Jekyll
    TEAMMATES (backend) Java
    (frontend) HTML, SCSS, TypeScript
    (backend) Gradle
    (frontend) Node.js, Angular
    (others) Selenium, Docker
  • All internal projects use Git. Learn advanced Git features such as rebase, squash, blame, bisect, etc. Other tools you can learn are given in the table above.