Right within a lesson you may be working on you are able to edit a typo in a lesson or make a suggestion to make something clearer for other students coming through the program. This feature is one of my favorite things at Flatiron, as I feel like I am contributing, even if only in a small way, to help make Flatiron School an even better place for students to learn how to code. In this way, technically, I have been contributing to Open Source since I have been enrolled at Flatiron School.
Each time I submit a pull request to make a small correction on a lesson that I am working on and it gets accepted, I feel a small sense of accomplishment and satisfaction. Although these contributions have just been correcting small typos or adding a missed word to a sentence, they are totally valid contributions that contribute to the greater overall project. Yet, despite these opportunities, I have been looking forward to a time when I can contribute in a bigger way.
This week, I read a post by Kent C. Dodds titled First Timers Only, that influenced my resolve to be a contributor to Open Source one day. In this post, Kent explained how he decided to get involved in helping first time contributors being able to contribute to Open Source more easily.
Make it as easy as possible. Say exactly where the code needs to go and recommend a good approach.
I have read similar things before about contributing to Open Source projects and vaguely remembered that there are some project managers out there that do take the time to make submitting your first pull request easier, so this wasn’t an entirely new concept for me but this week it seemed to sink in.
While reading Kent’s post I clicked through to some of the resources he linked to in his post and next thing I knew, I was messaging a project manager on Github, requesting to take a shot at one of the issues he had tagged as a ‘first-timers only’ issue.
As far as coding goes, it is was a very simple problem/issue. It was a simple design change, replacing pipes that separated some content with a few spaces. Yet, following the steps that the project manager outlined in their CONTRIBUTING.md file of creating a feature branch, pulling down the master repo, rebasing the master with your feature branch, opening a new pull request and submitting it, was a nerve wracking process!!
Although I had contributed to Flatiron School repos, I felt like in some ways it wasn’t the real thing. I was a student at Flatiron School. I am a Flatiron family member. They have to accept my contributions (if they are correct) because I am one of them.
It made me think of something my Mom used to say when I was growing up, if I had a problem with a friend or was let down by someone. Mom always said,
“In life there will always be problems and difficulties with people and sometimes they won’t like you in the end, but your family will always love you and accept you for who you are.”
Contributing to a repo belonging to a total stranger on Github is a bit (ok, a lot!) intimidating. They don’t know me. They don’t know if I know anything about coding. I am a no one to them. They don’t have to accept my contributions.
Yet, lo and behold, my pull request was accepted!!
Although it was a bit nerve wracking, and not entirely without some procedural errors, it was a really good learning experience. So much so that I have found a few more issue that I am confident I can tackle.
I could have easily talked myself out of even trying to contribute if I looked at ALL THAT CODE and let myself get overwhelmed and say to myself, “I don’t even know what half (probably more than half!) of this means?!? What am I doing??” But if you just focus on the problem at hand, which in this case was replacing a simple symbol with another symbol, the task is so much more manageable and very do-able!
All this to say that, as a newbie in the big world of tech and coding, there are issues that I am able to contribute to out there and so could you! My suggestions to others looking to contribute to Open Source, is just do it!