Lab 1 : Our First Open Source Contributions

So for Lab 1 our tasks were fairly simple. Find a partner to review a repo on and make contributions, no matter the scale, to their code. Be it a suggestion for their code, reporting an issue, or even fixing up small details in their readme.

So through slack I partnered up with one of my coursemates Niaz

Much like me, he wrote his code in nodejs, so it was perfect since I can go through his code easier through my understanding of node. His code, though written in the same language, differed from mine a lot. For one, he didn't use yargs so he had to process the arguments manually, and secondly he didn't use fetch and opted for a module called linkinator. No problem, in fact it's an opportunity for me to understand the logic and components that he used.

I forked a copy of the repo, cloned it and tested it out for myself. The code worked perfectly as intended and processed urls well. Functionally, I couldn't find find anything in the code I could identify as a flaw or improve. But I did realise that an empty argument passed in the program gave a very brief and vague description on how the url is used.

So I suggested that he add a -help option indicator to let users know what arguments they would need to obtain more information.

When I first cloned the repo, my visual studio code suddenly went red and I was briefly confused. But I noticed that the repo included his visual studio code settings folder and I thought it was unnecessary to keep in the repo so I suggested that he remove it or add it to his git ignore.

Finally, I also noticed that he intended to make unix style arguments (/v, /h, etc.) functional but hasn't written the logic to indicate those arguments, therefore they don't work. No worries, I just submitted an issue to let him know, and to update the readme to reflect that feature as well.

In return for the above task, Niaz reviewed my code. He filed 3 "issues" for my program. First was that I used to many vars and that I should change them to let and const. That was pretty insightful, I went on to read about the pros and cons for the different variable types to understand the use and brush up my knowledge of it. Secondly my readme was a bit too short and vague so now it's filled up with more useful a info, a graphic, and a license notice at the bottom. I do admire well made readme's from other repos I've come across in GitHub so I decided to learn a bit on how to deck out mine and it doesn't look half bad

Now the last issue he filed was just a suggestion, he mentioned how my code was all in one file. He mentioned that it would be a good idea to break the code into pieces, and make the code in the bin folder only include an instance of a shebang line (and a few other lines) and that it could manage my code cleaner. But he also said that it's not a big issue yet. So for now I'm leaving it as is, but I will take his advice to heart and keep it in my mind as I build my code and it grows in size.

All in all, I felt this was a valuable experience and a good step in the right direction towards more open source contributions. I definitely look forward to those opportunities!

and for anyone intersted in Niaz's repo


Thanks for reading :)

Comments

Popular posts from this blog

Release 0.3 : Telescope and The Quest for Infinity.... Scroll

Introduction

Git : Rebasing Refactoring Amending