[SPO600] Lab 1 - Code Review

Ronald Makalintal — Fri, 01 Oct 2021 10:03:06 +0000

Introduction to Lab 1

For our Lab 1, we were tasked to review two open source software packages which have different licenses. One of the software package that I've chosen is QGIS—an open source, cross-platform geographic information system software used to read, update, and analyze geographic and spatial data. Another software package I picked is Brave given that I am a fan of the free web browser's privacy-keeping features. QGIS uses the GNU GPLv2 license while Brave makes use of Mozilla Public License 2.0..

Analyzing QGIS's Code Review Process

Getting involved with QGIS's community is a straightforward process using GitHub. Users of QGIS can make a bug report through GitHub issues. The bug report contains the usual following details—expected behaviour, actual behaviour, steps done to reproduce problem, reporter's machine's specifications, and additional information seen as vital. In one of the bug reports that I had checked, three people were involved—the reporter of the bug, another person who dealt with an identical issue and had referenced that bug report in their own bug report, and the contributor. From what I could tell from their conversation, the reporter managed to convey the issue quite well as the contributor was able to recreate the same concern. Their way of communication eventually led to a quick fix as the bug was fixed not more than 2 days. I find that the reporter properly documented what they had experienced; thus the contributor pinpointed quickly what the issue was and deployed a fix immediately after. The bug report itself was labelled correctly as a bug, too, which is great as this habit of labelling concerns makes everything organized.

Analyzing Brave's Code Review Process

Now, upon checking Brave's Code Review Process, the Brave community also makes use of GitHub to properly sort out and fix any concerns with the web browser. I checked out a bug report which piqued my interest given that the author of the bug report was also the contributor who had fixed it. Due to this, there was only a single participant in the bug ticket. In the contributor's pull request, the contributor ticked all the checks in the submitter checklist as they had properly resolved the concern from what I see. Of the two reviewers, one had approved the changes made by the contributor; thus successfully merging the changes in the master branch.

Final Thoughts

From what I currently know about open source development, I could see that both QGIS and Brave communities made use of GitHub to properly sort out any issues with their respective software packages. Bug reports and feature requests were filed by community members, and were solved by fellow community members as well. Though I may be new to open source development, I do know a bit about ticket escalations as my previous job required me to file tickets on bug reports and feature requests as documented by users. The act of replicating the bug reports dealt by users was all too familiar and I am glad to know that I could transfer some knowledge I got from my previous job to my current journey in contributing in the open source community.

Now back to how QGIS and Brave communities handled contributions/patches from their communities, it was great to see how both communities dealt with concerns regarding their software. For one, I loved how community members could file concerns through GitHub's Issues section (QGIS / Brave). Their issues were properly sorted too using labels as they sorted out which ones were bug reports or feature requests, which ones needed to be dealt with immediately, etc.. I love how Brave makes it clear that you don't necessarily need to code in order to leave an impact in the software. Following along how a contributor in Brave submitted a patch, I would make sure to tick all the boxes in the Submitter Checklist so that I am confident that I am following the community's guidelines in properly contributing to the project. The checklist includes acknowledging the existence of a ticket regarding the issue, requesting for reviewer(s) if needed, and properly labelling the issue. Its also required to write a good commit description. QGIS's process of patching seems to be different as there was no mention of any submitter checklist-like section in a patch. However, the commits were given proper description and the concern was labelled correctly still.

My thoughts regarding this lab are overwhelming, to say the least. A lot of the things I read about did not make complete sense to me owing to my beginner knowledge of open source development. The documentations on how to contribute properly to each community existed, but I still felt overwhelmed as the issues touched hundreds of lines of code which I couldn't completely understand. However, this only motivated me to learn how code review processes worked in open source development as I would like to contribute significantly to the industry.

First ever blog post as a programmer!

Ronald Makalintal — Thu, 23 Sep 2021 09:00:05 +0000

printf("Hello world!");

I am Ronald Makalintal, an aspiring software developer/computer programmer currently studying at Seneca College. I have been studying software development since May 2020, which was also the time I started studying at Seneca. Previously, I studied Business Management back in the Philippines, but after completing the program, I reflected on what I wanted to do decades from now and decided that I wanted to make a significant impact on the world through making stuff. Now, 'making stuff' is, to be frank, quite vague. However, I did always see myself staring in front of a computer screen until the day I expire so I thought to myself, "maybe it wouldn't be a bad idea to start a career making computer programs?". More than a year has passed and I can confidently say that I am happy with the decision that I have made, and I would like to share with you all what I continuously learn—both inside and outside of the classroom.