My first contribution to an open source project
Have you ever found yourself in an infinite loop like this?
- Am I good enough to contribute code to a library which is possibly being used by other developers?
- What if I break something?
- I’m a newbie and still scared of getting exposed to the community.
- Sigh. I’ll just do nothing.
Good news: You’re not alone. I was in that loop until I forced myself to crash out.
“what you are afraid to do is a clear indicator of the next thing you need to do.” — Anthony Robbins
Let me tell you how I pulled through!!!
I stumbled across an article written by Anna Chiara Bellini (Director of Engineering at Toptal) and another article about the fact that apparently “women write better code”. I quote this from the last article:
Computer code written by women has a higher approval rating than that written by men — but only if their gender is not identifiable, new research suggests. They found that pull requests — or suggested code changes — made on the service by women were more likely to be accepted than those by men.
These two posts really inspired me as I pondered on the content. After a lot of contemplation, I finally took the bull by the horn. I made a research and eventually settled down for Helpy to start with (it was a love at first sight thingy) because of the following reasons:
- Helpy is a modern, “mobile-first” helpdesk alternative built with Rails. It can be used as Support Ticket, community support and customer communication system within an organization.
- I got fascinated by the following technical features.
- Email Support Tickets: integrated with Sendgrid, Mailgun, or Mailin.
- Knowledgebase: Full text searchable and SEO optimized.
- Community Support Forums: Customers and Agents can both answer questions in a public forum.
- Pre-wired for Google Analytics: Track everything from article satisfaction to what your agents are doing automatically.
- Mobile-First: Responsive design, works on all devices!
- Multi-language: Provide support in multiple languages at the same time.
After I forked the repository, I picked one of the issues, the problem of not being able to attach pdf files on support tickets. For newbies, It’s important to note that you should go for an issue you’re a little bit familiar with. I personally picked this issue because I have a previous experience working with Cloudinary .
As I worked through it, I had a few challenges:
- Learning to write tests with the default Rails minitest; In the past, I’ve always been using Rspec and never tried T.D.D(Test Driven Development) with minitest before.
- The project used a combination of Cloudinary to store files and Attachinary to upload files. However, there was a limitation to what attachinary can do in terms of previewing the thumbnail of a pdf upload. Figuring a way out of the limitation wasn’t an easy peasy.
- I also had to learn some new git commands; making a pull request to an open source project, updating my local files(code) with latest changes made to the project online.
Overview of what I did.
- Stage 1: I read the README.md on the project to know more about their contribution guidelines. I took a step further to read Attachinary’s documentation since I had never come across it until then. This is to get myself familiar with its functionalities, methods and how it can be used in a project.
- Stage 2: I added some lines of code to enable pdf’s upload where necessary. The next step was to preview the pdf as a thumbnail. This was where I got stuck for a while since attachinary gem had a limitation on previewing pdf’s. I eventually wrote an helper method to preview the first page of the pdf as a thumbnail. I tested this worked on all views that allow uploads of pdf’s after which I made a pull request. I was asked to refactor part of the code to make it look neater and voila, my pull request was merged.
Things I learnt so far:
- Before even writing any line of code, check out the CONTRIBUTION.md guideline(Some project might use README.md). This is highly important since you need to contribute some code according to the repo needs.
- Don’t be shy or timid to reach out to other developers on the team via available means e.g Gitter, Slack, etc. In my own case, I emailed Scott, (the creator of the Project), and requested that he add me to the Slack team and Trello Board. Scott made my first contribution experience quite interesting because he was available to give a brief detail of the codebase.
- You need to be quite comfortable with Git CLI. Check out one of our post hereabout Git.
- Always update and improve the documentation as well as the tests of the project.
- Be ready to communicate and argue for your proposed implementation and also be open-minded to have code reviews. Be open to defending your proposed implementation. Don’t be a “Yes-man” because your pull request needs to be merged by all means.
- Looking at other developers’ code exposes you to new ways of doing things. Prior to Helpy, I shied away from minitests, neither have I used Attachinary before. And now, I got to raise an issue I found in the Attachinary gem and hopefully get to work on it as soon as it is possible.
- Be patient through iterations and review cycles. I had my code reviewed twice because there were suggestions on refactoring some part of the code.
- Contributing to open source is fun. You get to work with other developers outside your circle. Scott was one person I could easily crack jokes with. At a point, we could gist about our daily job and where we live. I got to learn more about his culture too. It leads to building amazing relationships with people.
If you ask me about my experience so far: “it’s scary. But Incredibly Rewarding!”
If you like this post, don’t forget to recommend and share it. Check out more great articles at Code Like A Girl.