DPS909 Release 0.1: Contributing to Open Source

Hello Everyone,

I’ve moved over my blog to WordPress, as I find its interface to be more user friendly than Blogger. That being said, I’ll provide links to my previous posts below:

Blog 1: Windows Calculator

Blog 2: My Note App

Now, let’s move to this week’s discussion!

Last week in DPS909, my fellow peers and I were tasked with creating our own note taking apps. My previous blog introduces the features and technologies of my app.

This week, we got the chance to contribute to our classmates’ projects. We were instructed to contribute to two separate repositories. In one repository, we would fix an existing bug. In the other, we would introduce a new feature not currently present.

Part 1: Finding an Existing Bug

Searching through my classmates’ repositories, I came across this one. At the time, the interface of the app was relatively simple. It mainly consisted of a title with instructions and an editable div that spanned the browser window in which user input could be entered. No CSS (styling) had been implemented either, giving the app the appearance of a blank page. A quick bug I thought I could fix was the size of this div. Since the div is meant to store user input, I thought it would be useful if the user could edit the size of the div to their preferences, similar to how other notepad applications work.

Filing the issue

When collaborating with others on an open source project, it is best to file an issue on their repository. Under the issues tab, select to file a new issue. You will then be prompted to file the issue in a new window. After describing the issue, submit it. Here is the link to my issue.

The Fix

To start fixing this bug, I forked this repo to my Github account. What forking does is copying the contents of an existing repo and adding it to the repositories under your account.

From there, you can clone this new repository to your local machine and continue editing at your leisure. You should always add changes to a new branch, rather than working on the master branch.

The fix was relatively simple, consisting of adding styling changes in the div’s css selector.

After writing this new code, I added and committed the new changes on to my branch, issue-3.

Making the Pull Request

To notify the author of the project, a pull request is required. To do this, select to create a new pull request on the forked repository. After filing the request, submit it. The author will receive notification of this, and will choose whether to merge changes on your branch to his master.

I was happy to learn that the author of this repository accepted my changes, and merged them to his branch, as shown below

And now here lies the tangible proof of my first success in contributing to an open source project.

Part Two: Adding a new feature

In this project, I found that the user could save their input by pressing a save button. I thought it might be efficient for the user to save their input using the keyboard, so I conveyed this when filing my issue. I decided to implement this with the Hotkeys.js library, as I had used it in my project. However, I did not receive a response from the author. Despite this, I carried out my implementation in the hopes it would be accepted. Unfortunately, my changes were not merged by the author, which made me learn that not all people will accept my code solutions. In hindsight, I should have probably waited for a response. Here are links to issue and pull requests.

Part Three: Reviewing Pull Requests on My Application

On my project, one pull request wanted to add a save button to my app. A second pull request would introduce an autosave feature to my project. I reviewed how the code requests would affect my existing, accepted both, and merged them on my master branch. On another pull request, another contributor accidentally pushed that would cause my app to produce alerts upon auto saving (shown below). He committed another update to that mistake, which I accepted. Again, it goes to show that even supposed ‘fixes’ can introduce more bugs to a project. Avoiding this requires a thorough examination of the code.

Part Four: Review

Overall, I found this assignment to be enjoyable introduction to open source development. I marvelled at the improvements in my app that resulted after others’ contributions. These included a new save button, distinguishing the div of the notepad with a border, and an auto-save feature. Coding these features by myself would have taken a lot more time and learning. However, letting others work on my project gave me new insight on how to code these features. This, in essence, will actually save me more time in the future. This assignment demonstrates the beauty of open source. It welcomes everybody, regardless of their skill level, and provides an open space to contribute and learn from others.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website at WordPress.com
Get started
%d bloggers like this: