Site icon Paradite

[CS3281] Development processes of open source projects – socket.io and Teammates

During the course of CS3281, I had the chance to work on two different open source projects, socket.io and Teammates. There are various differences between the nature of the two projects as well as the development processes.

Socket.io

As a popular framework for real-time communication on the web, socket.io has many characteristics of a good open source project:

In terms of the development processes, there were no clear documentations on the process. Instead, we communicate our progress with our project mentor and get feedback directly. The Pull Requests tend to drag for days or weeks before it gets properly reviewed.

For a widely used project like Socket.io, the development process should be improved in terms of manpower. A possible way of this solving the issue is to recruit a dedicated team of people who had experience with the project and have the free time to help maintain the project. In the long run, there can be additions and withdrawals from the team but there should be always be more than a few developers there so that issues and pull requests can be handled in a timely manner.

Teammates

Teammates is a peer evaluation platform for project teams. It is widely adopted across the world in hundreds of institutions. As a project that came out of an educational institution (NUS) with a lot of human resources, it is quite different from a typical open source project maintained by a single developer or a few people. Some of the characteristics of the projects are:

During the development process, there are various documents to read and a number of guidelines to follow. The Pull Requests are reviewed actively within hours by the project core team with high requirements of the coding style and code quality.

A possible area of improvement is the automation of the code review process. Currently there is no cloud integration test to check for build errors, test cases and code styles. A CI (continuous integration) service could be added to automate the test process and check the code style against a predefined standard. For JavaScript, the coding style can be checked by integrating  eslint into the codebase and the CI, which saves the time for both developer and the reviewer for common styling issues like whitespaces and indentations.

Comparisons

 

Exit mobile version