Open source: first two pull requests merged!

In my last post, I took my first steps into open-source contributions by contributing a hotfix to a fellow student’s open-source “Notepad” applet after discovering a small issue with it. Although that pull request still currently remains open, I am proud to report that, in the meanwhile, I have since successfully contributed code to two other open source projects!

my-lightweight-noteboard – bug fix

my-lightweight-noteboard by vitokhangnguyen is a newly-released open-source applet that describes itself as “a serverless note taking web app”.

When playing around with the applet, I noticed that its styling was not yet optimized for smaller screen sizes. Specifically, I noticed that, on smaller resolutions, text nodes within the header section were overlapping and conflicting with each other:

my-lightweight-noteboard: display bug on small resolutions
my-lightweight-noteboard: display bug on small resolutions

To handle this bug, I performed the following steps:

  1. Opened a new issue in the project’s repository.
  2. Forked, cloned and branched the project to investigate the cause.
  3. Discovered the culprit: a few restrictive custom styling rules.
  4. Committed and pushed a bugfix to my fork, referencing the issue.
  5. Created a pull request (from my fork’s dedicated branch).

My pull request was graciously accepted with a reply from the author. (On a side note: while I was fortunate enough to have a chance to showcase my requested changes to the author, in-person, I have also learned that it is important to ‘sell’ your changes to a project using proper documentation and thorough description, both in GitHub issues and pull requests. I hope to improve at this as I gain more experience.)

For more information on this my-lightweight-noteboard, check out the author’s blog post:

my-note – new feature

After contributing a bug fix to my-lightweight-noteboard, I sought out a project to contribute a new, desirable feature to—and I found my-note by shmooey.

Like my-lightweight-noteboard, my-note is a newly-release open-source applet that describes itself as “a web based note taking app”. In a blog post discussing the project’s release, the author mentions a desire to add “clear” and “save” buttons to the applet. I saw this as my opportunity to contribute.

I noticed that the author already opened their own issue concerning a “clear” button, so I opened my own issue to add a “save” button. Following a methodology similar to the one I followed to contribute to my-lightweight-noteboard, I eventually created a pull request to pull my commit that added a stylized save button.

However, after creating that pull request, I realized made a mistake: I had forgotten to reference the issue in the message of the relevant commit. Here is how I handled this (and what I would change):

  1. I ran git commit --amend, which allowed me to edit the message of my local commit.
  2. I pushed* the renamed commit up to my fork (which, as I have learned, must be treated as a separate commit), adding it to my pull request.
  3. I merged my prior two commits.

(*I have since learned that it is common practice to use the --force flag to push amended commits. While I did not use that flag in this instance, I will certainly attempt to be more prudent when modifying commit history in the future.)

After reviewing my pull request, the author requested a minor change:

"Can you implement [the save functionality] as an event listener in JS instead?"
GitHub offers excellent tools to aid requests for line-specific code changes!

I was quickly able to implement and commit the requested change, and the author subsequently accepted my pull request. Overall, contributing to this project presented an excellent learning experience in and of itself!

For more information on my-note, check out the author’s blog post:

Zennotate, the subject of my last blog post, has not yet been fortunate enough to receive contributions from my peers (despite in-person efforts to advertise the project) or the broader open source community. I am, however, holding out hope that others will yet take interest in this project. If you are interested in contributing to Zennotate, please feel welcome to open an issue on its GitHub page!

Reviewing two peer-made pull requests

While Zennotate awaits new contributors, I thought that I might review a few pull requests made by my peers. I picked out two specific pull requests, each of I found interesting for different reasons.

micro-note – “Issue 2 add a clear button #3

ragnarokatz did a fantastic job with this pull request!

  • They chose a strong, common name for their working branch, initial commit and pull request.
    • This naming scheme makes it immediately clear that these three elements (branch, commit, PR) all belong to the same line of development.
    • As a branch name, “issue-2-add-a-clear-button” is, in my opinion, far more useful than “issue-2”!
  • They provided their pull request with a minimal and effective description: a bulleted list of changes to-be made.
    • Each of the two commits, apparently added after the creation of the pull request, clearly and intentionally match the two bullet points of the description!
  • Nice feedback (in comment form) was provided by the repository owner, as well.
  • (On a side note: it looks like repository owner may have mistakenly closed this PR instead of approving it. However, it looks like the owner had no problem subsequently re-opening the PR and merging the changes.)

tinyNote – “Issue 2 add a clear button #3

I wanted to highlight this pull request not because of the interaction between the requestor and repository owner, but because of an interesting comment made by a third party:

A commenter documents a bug introduced by this pull request
A commenter documents a bug introduced by this pull request

Apart from being very well-styled (with both code blocks and inline code formatting used effectively), I found this comment by vitokhangnguyen interesting for how it effectively functions as a link in the chain of development in several ways:

  • The comment links the current pull request to a previous pull request.
  • The comment hints at the creation of a future issue (which will necessitate a further pull request, continuing the chain of development onward…)
    • (If I were to suggest one improvement: in place of using this comment to suggestion a change, I think it would have been better to either outright state their intention to open a new issue to address this suggested change. Alternatively, that issue could have been opened beforehand, and then quoted in the comment.)

Published by


Software Developer

Leave a Reply

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

You are commenting using your 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