Open-Source: My Release 0.1

In my first assignment for my open source class we had to file issues, create pull requests and potentially review issues filed in our own repos we created in our lab 2.

Issues Filed:

The first was a fix to improve efficiency of the note app that was using an input field restricting the app to a single line.

The second was to make an improvement and upgrade the note app to use the rich text editor Quill.

Pull Requests:

The first pull request I made was to fix the input type for the notepad. Here the creator of the repo was using some basic bootstrap CSS, so i had to remove of the divs that wrapped the content of the input field and buttons as they were input specific divs from the bootstrap CSS. I then replaced the input tag with a textarea tag so that a you could write full paragraphs or take point form notes, etc.

The second pull request I made was wasn’t to fix anything but to upgrade the app for a better user experience. I did this by taking the simple textarea and replacing it with the Quill text editor and upgrading the previously implemented functions to work with the new implementation.

Reviewed Pull Requests:

Unfortunately I did not get the chance to review any pull request in my own repo as none where filed and no pull requests where made at this time.

Things I Could Have Done Differently:

I believe there is a lot of room for improvement, especially in my first issue/pull request. unfortunately I completed this one before an important lecture that taught me so much about the contribution process using git and GitHub. Not only did I learn some more useful git commands like log, show, diff, etc. that will give me a better understanding of what I’m doing but show me exactly what i have changed which helped me avoid pushing my second request with unnecessary white space.

In my first attempt I realize I probably should have included a code snippet since it would be considered a bug fix and would give context to the user reviewing the issue.

I also filed the issue and then completed a pull request right after without waiting for a confirmation. I believe this was wrong of me to do. Even if I fork the project and “fix the issue” I filed before I get the go ahead from the owner(s) of the repo I should wait to actually make the pull request and just commit the changes to my local branch using the descriptive keywords so that it links in the filed issue. This way maybe what I viewed as a bug had a reason it was done in this way and for the time being should not be changed but by linking my commit even if the issue is closed will at least show eagerness to contribute to the project and could lead to them directing me to a different issue that doesn’t have anyone currently working on it.

I do believe my second attempt much better, but there is always room for improvement and I’ll be expecting a lot of rejected pull requests that will help shape my improvement moving forward

Published by marss64

Computer Programming and Analysis student at Seneca College, Toronto. C/C++, Java, Linux, Android, SQL, and Database Administrations.

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: