CATcher:
MarkBind:
RepoSense:
TEAMMATES:
NUSMods is the official course catalogue, module search and timetable builder for the National University of Singapore (NUS).
The main feature of NUSMods has to do with the timetable builder which provides a stable and easy platform for NUS students to plan their timetable and examinations for that particular semester.
Currently, NUSMods is also developing another feature for undergraduate students to plan their modules over the 4 or 5 years of their student life in NUS.
During my time in NUSMods, I worked on a range of aspects with regards to the codebase for NUSMods.
PR: PR #3343 Reduce Code Duplication in utils/ical
Tools Learnt: Typescript
Issue Tackled: Issue #726 Reduce Code Duplication in utils/ical
For my first PR for NUSMods, I handled a good first issue which tackled code duplication in some of the utlity modules for the retrival of lesson time in hours and minutes.
PR: PR #3348 Fix Cropping Out of Dropdown menus
Tools Learnt: Typescript, React State Management
Issue Tackled: Issue #2747 Module Planner - Dropdown for module card is cropped out
While tackling issues with the Module Planner, one issue is that the dropdown menus for modules are cropped out and thus, cannot be deleted or edited. Thus, with the aid of React State Management and HTML / CSS, the bug was fixed to ensure that overflow did not happen.
PR: PR #3374 Add Toggling of Prerequisites Checks for Planner
Tools Learnt: Typescript, React State Management, React Redux
Issue Tackled: Issue #3369 Allow removal of yellow warnings in Planner
For my first feature developed in NUSMods, a simple toggle was created to allow students to turn off and on prerequisite checking for the modules that they plan to take, as NUS API can be outdated and does not include revamped modules.
The workflow is the same as how CATcher operates, where we practice trunk-based development and do deployments via the master / release branch.
Pull Requests get reviewed by NUSMods developers and need to pass checks via Vercel to ensure a stable system after the Pull Request has been merged.
Credits: Contributing Guide
Feature Suggestions
For large-scale OSS Projects, it is important to consider about most students before proceeding with a feature.
Large Codebases and Documentation
For large-scale codebases like NUSMods, it becomes much easier to understand the logic with documentation. This is something CATcher can learn from as well via their rich documentation in the codebase.
Pull Request Reviews
One possible area for improvement will be to get more developers onboard. As NUSMods becomes a staple in years to come, the team can get current NUS undergraduates onboard to review and discuss feature development.
Workflow Explanations
Currently, their workflow documentation is only available when talks occur via NUSHackers. In the future, it will be good to documentation their workflow via their GitHub Repository.
Mattermost is an open source platform for secure communication, collaboration, and orchestration of work across tools and teams. Mattermost provides three key tools: Channels, a messaging service for direct and group communications, Playbooks, a task manager to plan and run repeatable processes on project situations such as campaigns or incidents, and Boards, a collaborative project manager.
Mattermost was originally proprietary, but have moved to open-source as the first version was published in 2015. Over the years, it has grown into a big player in its field, competing with proprietary team messaging applications such as Slack.
The Mattermost codebase is hosted in GitHub as the Mattermost organization. Some of the key repositories in the organization are mattermost-server, which handles the core backend functionalities, mattermost-webapp, which is the web frontend service for the platform, and mattermost-plugin-playbooks, which is the full-stack plugin for Playbooks.
I took on specifically contributing to the Playbooks plugin as there are many community-friendly issues posted for the plugin. I started out small with editing the data representation and display on user-facing features. My first contribution is updating the options text on a snooze timer for status updates such that it will be displayed as for 60 minutes, and so on with other durations. Although trivial at first glance, it turns out that I need to do more than just literal text substitution. The durations do not only come from literal string representation, but also procedurally generated through the playbook defaults and the user's previous choice of duration. I had to understand how the flow of data between the frontend components first to gather the function that generates the texts for the runtime durations.
I then picked up an issue to specifically explore the interaction across services when Mattermost is run. The issue asks to match the description field limit on adding and editing a Playbook Task as currently, which seems quite straightforward, but it turns out that these two actions are displayed through vastly different endpoints: the edit task UI is rendered by the plugin webapp service, while the add task UI is rendered by the core webapp service. To discover this, I had to trace from the plugin webapp, to the plugin backend, cross over to the core backend, and end up at the core frontend. Through this, I became acquainted with the way the plugin service interacts with the core service. The knowledge becomes important as the fix is to understand the core backend API parameters and modify the communication body between the plugin backend to the core backend to override the default length limit at core's side.
Links to Pull Requests
Community contributors would need to go through the contribution checklist that outlines what to do and expect out of creating a code contribution.
Issue management for various areas of the app is done in the mattermost-server repository, although some issues may span across multiple repositories. For example, many issues related the Playbook plugin are posted there, even though it actually resides on a different repository. Another instance is that there are issues that require changes in multiple repositories at the same time, such as in mattermost-server and mattermost-webapp.
For the review workflow, in my opinion it is largely the same as MarkBind, in that it is mostly a conventional merge workflow to the master branch. Although, one key difference is that there is a sequence of reviews in the approval process, meaning a pull request must be approved by more than one person. I encountered a total of 2-3 reviews, each assuming different positions in the team: the first review is by the Developer reviewer, then the second is by User Experience (UX) reviewer, then the final one is by the Quality Assurance (QA) reviewer.
I had my first experience on running services with Docker as I have to run the server and the webapp at the same time in order for me to be able to deploy the Playbook plugin. As I am using Windows with Windows Subsystem for Linux (WSL), there were some setup involved before I can easily run the project, such as integrating Docker from the host OS to the WSL distros, creating links between the systems, and more. It was a good learning experience for me. Once I have set it up, running the server becomes a breeze.
I also learned about Webpack and how it can help watch files and recompile for changes, especially in webapp files, which gives us ease of use to the development of frontend features.
One thing I found fascinating is that type-safety is important in Mattermost, as it is using Typescript for most of the webapp code. I saw types rigorously defined in the code files, which gives the developers a sense of security that the data that are passed around is of a certain type. I feel MarkBind can move towards being a type-safe project as well for the convenience of the developers and the system as well.
phpMyAdmin is an open-source tool, written in PHP, to provide a user-friendly and intuitive web interface to handle the administration and operations of MySQL or MariaDB databases. The tool is frequently used for managing databases, tables, columns, relations, indexes, users and permissions. It also has the ability to directly execute SQL statements. phpMyAdmin is widely used and well documented. This project was started in 1998 and has since become the most popular administrative tool for MySQL databases, especially for web hosting services such as cPanel. It currently has over 1.1k contributors. phpMyAdmin is a mature project with stable and flexible code base.
For my contributions, I focused on the issues related to the frontend components. I started off by working on a simpler issue, adding the attribute autocomplete="off" to the Change Password and Login Information forms to fix an issue of having random values being populated into the fields of those forms. For this task, I had to first locate the respective components that contain the forms which was quite straightforward.
For my next contribution, I worked on fixing a bug related to the Copy to clipboard feature. The Copy to clipboard feature allows users to copy the result from an SQL query. The copied query result will be placed nicely in a table form, in their respective rows and columns. However, when there were NULL values present in the result, the format of the table would be messed up and the copied query result is no longer usable and hard to read. For this task, I had to first locate the component responsible for generating the copied query result. I did this by tracing the code when the Copy to clipboard button was clicked. Next, I had to investigate why NULL values were causing the formatting of the table to be wrong and I eventually found out that the reason was because they were wrapped in an <em> tag, which would cause a newline to be generated in their text() method. To resolve this, I added a function to check for the presence of <em> tags in the query result. If an <em> tag is found, extract the content out so that the text() method will produce the correct formatting.
For my third contribution, I worked on resolving an issue related to the UI component. For this particular issue, the usage of <code> tag was not working on one of the components and was instead showing up as raw string. For this task, I had to locate the component that contained the relevant code. However, the code was in a generic Description file and the issue did not come from the file itself. Then, I tried to find out which particular component used this description and finally discovered that the issue was coming from a method that sanitizes codes. This method causes the input with <code> tag to be treated as raw string and hence the browser will not process it as a HTML code. To resolve this, I replaced the usage of <code> tag with BBcode, which will return a valid HTML element in the sanitize method.
Links to PRs:
Set autocomplete off for 'change password' and 'login information' forms #17226
Fix #17228 - Resolve formatting of copy to clipboard with NULL values #17232
Fix #17348 - Resolve formatting of in Preferences > Export #17350
The typical workflow of phpMyAdmin for contributing code can be found in their contribution guide. First, fork the repository and create a branch for new changes. Then, once done, open a new pull request from that branch against the relevant branch of the main repository. The pull request should be linked to the relevant issue and should contain a description of the changes. Next, the developers from phpMyAdmin will mark the relevant issue with the label has-pr. The developers will then review the pull request and if satisfied, merge it into the relevant branch. Comparing this to MarkBind's workflow, I think both of them are quite similar. One thing that I find interesting is the labelling of the issue with has-pr if there is already an existing open PR fixing the issue. I think we can also adopt a similar practice in MarkBind so that the issues that already have in-progress PRs can be quickly identified. This can help current and new developers to quickly filter out the issues that already have fixes and focus on issues that need to be fixed. Although GitHub provides the linked pull request label, I feel that this is not sufficient as sometimes an issue can require more than 1 pull request or has multiple components. In this case, having an explicit label would allow developers to know if an issue is available to work on.
In terms of setting up, phpMyAdmin requires PHP, a web server and either a MySQL or MariaDB to run on. A web server is needed so that phpMyAdmin can be accessed through the localhost on the browser. Instead of having to set up each of the required software manually which can be time consuming, especially for configuring Apache and MariaDB, a really quick way to set this up is to use XAMPP. XAMPP allows users to quickly set up a PHP development environment which contains Apache, MariaDB, PHP and Perl. It also handles the configuration of these services. The control panel allows each of the services to be started or stopped with a single click. I feel that this tool is really useful for developers that are working on projects that require PHP, Apache or MySQL/MariaDB. XAMPP really helps to streamline the setting up process and speed up the development.
Gutenberg is a plugin for the popular website builder, WordPress, which is usually included on all installations of WordPress by default. Gutenberg is a block editor tool that allows WordPress developers to customise the pages and posts in a modular approach. Gutenberg can create blocks that contain elements such as image gallery, paragraph, shortcodes, custom HTML and many more. Gutenberg is an open-source tool managed by WordPress. It currently has over 19 million active installations and more than 800 contributors.
I contributed to the project by fixing an issue related to the consistency of the UI component in the Site Editor feature. Previously, in the save panel of the Site Editor, the close panel button is an X icon whereas the close panel button on the Post Editor is a cancel button. To resolve this inconsistency, I updated the close panel button in the Site Editor from the X icon to the standardised cancel button.
Link to PR:
Site Editor: Update save panel's cancel button from icon to visible text #37310
The typical workflow for contributing code to Gutenberg can be found in their contribution guide. First, a WordPress development environment should be set up so that Gutenberg can be tested locally. Next, for the git workflow, fork the main repository and then work on the changes in separate branches. Once done, open pull requests from the branches in the forked repository to the main repository's relevant branches. Comparing this to MarkBind's workflow, I think they are both quick similar. With regards to code style and testing, both projects have their own set of rules, MarkBind mainly follows the Airbnb JavaScript Style Guide while Gutenberg mainly follows the jQuery JavaScript Style Guide. Gutenberg has some extra testing components such as end-to-end and performance tests, which MarkBind currently lacks but they are being considered currently in #1798 and #1544.
One thing I find interesting is setting up the test environment for testing the project. To test out WordPress plugins, a WordPress installation is required. Setting up a WordPress environment can be time consuming and tedious. One particular tool that WordPress has provided is a development package called wp-env. This package allows developers to easily set up a local WordPress environment for building and testing plugins and themes. It relies on the use of Docker with pre-built images that contain a LAMP stack (Linux, Apache, MariaDB, and PHP) and WordPress. Then, it pulls in the plugin or theme project folder into the Docker instance and serve it through the localhost. Developers will then be able to test their plugins and themes by accessing the WordPress instance through the browser on localhost. I think this method of using pre-built images on Docker can be really useful for developers to quickly start up development environments to test out their applications in different operating systems. For MarkBind, since it is mainly used on web browsers, there are instances which the output result is different when used on different web browsers and operating systems, especially for the styling of the components. I feel it may be a good idea if we can set up a few environments for MarkBind's developers to test out their codes in different operating systems and browsers. For instance, a Windows user currently will not be able to serve a site in Safari to see how it will run and vice versa. There are online services such as BrowserStack and Browsera which provide cloud servers to run Windows and MacOS to test out web services in the different browsers. However, most of these services are not free. One possible workaround that MarkBind developers can do is to run Windows and MacOS in VirtualBox. Usually, the images provided for MacOS will not be the latest version but it can at least give the developers something to work with. We can consider including a short guide on how the VMs can be set up and used for testing in our developer guide.
Gutenberg project also has the practice of prefixing the pull request's title with the component name that the pull request is working on. For example, if the pull request changes something on the Site Editor component, then the title will be Site Editor: .... I find this rather useful as it allows reviewers to quickly tell which component to look out for in that particular pull request and at the same time limit the developer to not make unrelated changes in that pull request. I believe MarkBind can also possibly adopt this practice of prefixing the pull request title and add this requirement to the guideline.
Godot Engine is a feature-packed, cross-platform game engine to create 2D and 3D games from a unified interface. It provides a comprehensive set of common tools, so that users can focus on making games without having to reinvent the wheel. Games can be exported with one click to a number of platforms, including the major desktop platforms (Linux, macOS, Windows), mobile platforms (Android, iOS), as well as Web-based platforms (HTML5) and consoles.
Godot, released in 2014, is currently the most popular open source game engine. However it still lags behind established proprietary game engines such as Unity or Unreal Engine which already have large communities, having been released much earlier than Godot. Godot is written almost completely in C++.
For my contributions, I focused on the issues related to the user interface components and compiler.
I started off by working on a seemingly simpler issue, selecting the file name in the dialogue box whenever a new file is created. For this task, I had to first locate the respective components that contain the dialogue boxes which was much harder than expected. This was as the UI was completely built from ground up using almost no external libraries. I had to trace the exact function which handles the window popping up, and specify the exact characters to highlight in the selection.
By my second contribution, I was more familiar with the code base, and I fixed an issue regarding how tree traversal was not handled properly. The existing code checked for the existence of a sibling of the parent, which caused a bug when the parent was an only child. This caused some lists opened in the UI to misbehave.
In my third contribution, I added a feature to the options menu in which double clicking an shortcut assignment would allow one to immediately assign a key to it. Although it seemed like a big feature to add, I was surprised by how most of the required functions required already exist. For example, a signal is already sent whenever the shortcut assignment is double clicked. I only had to figure out exactly which signals and variables were relevant. However there were many inadequately named variables which made it hard to pick apart the noise.
My last contribution was to fix a memory leak in the game script compiler. From my understanding of memory leaks, it can usually be solved by changing a single line. However I underestimated how hard it was to determine which line it was. Godot uses a custom garbage collection mechanism to track object dependencies, which allows one to free objects when all pointers to them are freed. The memory leak can hence easily be inferred to be caused by a circular dependency, in which the ancestor of some object is itself. As a result, the object can never be completely dereferenced and hence freed. The issue can be fixed by informing children about who exactly is referencing them, to prevent objects from tracking self references. There was already a function to do this, but it was not applied to all objects. Unfortunately, I was unable to completely resolve the issue.
Pull Requests get reviewed by Godot developers and need to pass checks via Github Actions to ensure a stable system after the Pull Request has been merged.
Credits: Contributing Guide
The preferred IDE for working on C++ is Visual Studio. I learnt how to compile C++ via visual studio as stated in the Godot compiling guide. I had also learnt how to use Visual Studio to examine and keep track of references in memory. I also learnt more about the overall structure of garbage collectors, and how signals are propagated through the code.
Godot encourages aspiring contributors to join the to join the Godot Contributors Chat. It is a somewhat active chat where people are generally willing to help. Currently, Reposense uses Slack as the main messaging platform, which is closed to outsiders. Opening an public messaging chat on discord for example would make it easier for newer contributors to ask general questions about the project.
Most functions are not documented properly. As a result, it can be fairly hard to determine what each function does, as well as what side effects they might cause.
Planning and execution of Notifications Banner feature. Link to planning documents.
As they say, fail to plan, plan to fail. With previous features that were done in past semesters, there were no planning documents that was kept in a central location that everyone had access to. As such, it was difficult to have a reference when coding and developers on the project will be unsure of the requirements or overall architecture of the planned feature. This made it very difficult for developers to all be on the same page and lead to lengthy discussions on Github Issues, PRs, Slack channels that can be resolved with a proper planning phase before execution.
With the introduction of the technical planning document in this semester, everyone working on the feature is clear on the backend design, architecture and frontend pages all at once. This made coding for the CS3281 students much quicker (hopefully) and we could also match their code against the requirements that were laid out in the document.
Continue to adopt the planning documents in future iterations of CS3281/2
Complete the whole SDLC cycle. That is, include a requirement gathering phase. The current technical document focuses very heavily on the technical aspects of the upgrade. In this iteration, we did not have a formal requirement gathering phase. The requirements laid out were thought of by both CS3281/2 students and approved at a later date. Since requirements are the foundation of any upgrade, they are the most important to get right before technical planning can begin. Having a formal requirement gathering phase (in the form of document or meeting minutes or any other suitable medium) will greatly improve the experience of the technical planning and implementation/testing stage.
ToBeYou is a Singaporean interactive fiction game that lets players experience the life of someone else. The game features the stories of a cast of characters of different racial, religious or cultural backgrounds, and in playing through these stories, players can answer mini-quizzes and pen down their personal reflections at the end of each chapter. As a whole, the project aims to cultivate empathy and spark interest in issues surrounding diversity and multiculturalism in Singapore.
Having worked on the project since July 2021, I’ve made a good number of contributions to the project.
For the main game, I optimized the front-end to scale with large amounts of data, as the number of user responses increased significantly since the product launch. I also improved the design of our database by introducing cloud functions and some denormalization to answer common queries faster. Example: #165 Add infinite scroll to reflections
Separately, I’ve been responsible for creating two new pages/sub-projects in addition to the main game. I created an administrator dashboard for administrators to view and moderate responses by players of the game. I also created a facilitator dashboard where teachers can view the progress and data of their students in the main game.
As for the technical aspects, I’ve become more skilled with technologies such as React and Firebase, and learned general techniques for dealing with NoSQL databases.
I’ve also learned more about collaborating with UI/UX designers when creating a new product, and involving myself in making important technical or design decisions. Personally, I’ve also learned that working on something meaningful is more rewarding than working on just ‘any’ open-source project.
GitHub actions to automatically preview on staging upon making a PR. This saves us the trouble of having to check out and run the code locally if it's just a minor cosmetic change that we want to preview quickly.
Using code formatters, in particular Prettier with ESLint. This us saves a lot of time worrying about code quality and fixing lint errors, and enforces a standard coding style in our team.
ToBeYou is a less ‘polished’ or ‘professional’ project compared to most well-regarded open source projects of a technical nature. We’re mostly a bunch of student developers with little experience, and our project is much more product-focused. We could definitely improve our code review practices, which are optional at the moment (sometimes we even push directly to the main branch). We could also improve on our public-facing works, such as READMEs and documentation, and make greater use of GitHub issues and PRs as a means of communication and project organisation.
This semester we are introducing a new feature which involves quite a bit of planning and execution. The development team consists of 4 CS3281 students, and the entire project is a full-stack project covering everything from back-end API, logic and database design to front-end UI and UX. The entire feature is fully tested, including front-end and back-end unit tests, as well as end-to-end tests.
TEAMMATES has come a long way, but there wasn't a way for us to reach out to our users besides sending emails. Even with emails, the original problem is still not solved - we want users to feel more connected with TEAMMATES, to know what is going in TEAMMATES. Hence, the Notification feature was born. With the new release on 16 April 2022, TEAMMATES users around the world will be able to login to the TEAMMATES portal and see the first notification from us. The notification system will allow the users to mark notifications as read, and browse through the history of notifications on a dedicated user notifactions page. For returning users, this is important as it gets them updated on how has TEAMMATES improved over the past months or years.Perhaps they will once again fall in love with TEAMMATES for the new features hardworking developers at TEAMMATES has brought to the platform 😃. On the other hand, with the new admin notifications page, the admin will have complete control over how the notifications will be displayed to the user, be it the style of the notification or who the notification is targeted at.
My contributions as a mentor includes giving general directions, assessing blockers and prioritising objectives to ensure that goals are met within the given deadline. The bulk of my work also includes code reviews and ensuring that things go as expected.
As a mentor for this project, I have learned and grew together with the CS3281 students, and I will be sharing the takeaways from my experience as a mentor, and a reviewer.
As a mentor, it is important to establish communication with the mentees, so that it is convenient for them to raise issues and potential blockers early. Slack is our asynchronous mode of communication and I had to say that it has been an effective platform for raising quick issues, discussing possible solutions or even pinging each other for reviews. However, I do also realise that there are limitations with this kind of text-based communication, one of them being that it can be difficult to make sure that everyone is on the same page, without being able to see them or hear them. We can only assume that everyone has read the message and understood the importance of it or the intent behind it. In constrast, physical or online meetings allow for a continuous stream of conversation between parties to work out misconceptions and make things crystal clear. This can help to avoid miscommunications which otherwise could delay milestone objectives. On the other hand, face-to-face or online meetings also has its caveats, in that team members may feel shy to voice out or have yet to digest the conversation. Hence, a secondary asynchronous mode of communication via Slack is still important to "patch the holes".
As a reviewer, I realise the many tendencies of developers to go with their own style or way of doing things. It is quite natural for different people to approach things differently. While most of the code may not be wrong or affect correctness, in a software engineering project this would lead to a mess and it will present a lot of difficulties for other developers who see the code for the first time. Hence, while understanding the design and architecture of a project is important, making sure that new developers understand the importance of the coding standard is equally important. I have realised the importance of "nitpicks" to slowly adjust these tendencies and allow new developers to write code that do not stand out for the wrong reasons in the codebase. I have also observed that it takes time to push cleaner and more standard-consistent PRs, and as a reviewer, telling the "why" instead of stating the "what" when giving reviews is important for allowing new developers to learn.