I didn’t think about contributing to the projects I was using and learning from.
So thanks to Jonathan Neal: for his initial encouragement to contribute to a large open source project (angular.js for me). I only worked with him for a while, but his willingness to teach and help out left an impression on me.
When I started, I had so many questions and fears (like most people). How exactly do I get started? What can I even do? It seems as if everything is going smoothly without my help? Which project should I contribute to? And what if they don’t like me?
There’s just so much to learn: git, github, the project itself, not to mention the tooling/setup. It can seem overwhelming even when you know to look: most projects have a README, CONTRIBUTING, or an irc/gitter/slack.
I remember having some anxiety with my first pull request for angular. Before submitting the PR, I read everything possible about the project and contributing, acting like the perfectionist I am to make sure everything was correct (including code style, commit message, title). I’m glad that I don’t feel that self-conscious when writing this blog post though!
I could have added a short message saying it was my first PR (small plug for my chrome extension that I made to help maintainers with this).
I guess a gentle push was all it took for me to get started. There wasn’t a magical process; it was mostly unstructured and I figuring things out on my own.
That should definetely change for all the newer people coming into open source.
It is funny to note that now I just push a work in progress commit whenever. I don’t care about the title and ask for feedback immediately. Maybe I just feel more comfortable and don’t need to give some kind of impression to anyone. Instead I just willingly ask for the help of others.
Given I had no idea how anything worked, I remember looking through all of the open issues. I was difficult to find one that would be suitable for a first contribution. Thankfully, I found https://github.com/jscs-dev/node-jscs/issues/665 which had a beginner-friendly label.
It’s not always the case that there will always be simple tasks like this but it’s something that maintainers can work towards: efforts like https://twitter.com/yourfirstpr, and labels for beginners like in JSCS help a lot. I remember taking at least 10 minutes making https://github.com/babel/babel.github.io/issues/754.
It’s easy to find a simple issue or a typo and just fix it yourself but it could be someone’s first contribution. It’s “normal” to just work on features/bugs and hard to spend time on the building the community. It doesn’t seem to be a focus given all these projects start off as fun side projects and end up becoming overwhelming and in need of a project manager. And of course no one tells you how to do that and it’s not something most are prepared to do.
Shout out to Joel Kemp for being the first person I got to interact with on the project and for being so genuinely welcoming!
He and the rest of the JSCS team (Alexej Yaroshevich, Marat Dulin/mdevils, Oleg Gaidarenko, Mike Sherov) were just awesome in helping me contribute more to the project. The project had good contributing docs, a gitter room (pretty common now), and a simple project structure. Given the majority of the work was around linting rules it was easy to contribute (we had a file for the rule documentation, a file for the rule, and a test file).
Over the next months I did more docs changes, started going to other repositories to add JSCS, and submitting bug fixes.
Before I knew it I found myself looking through all the issues/PRs and watching the repo.
For a lot of projects, it does seem like it’s a rare sight to see a contributor doing more than a single PR. A lot contributions can seem like one time commits because there was typo while reading the docs or the user found a bug at work and became a contribute. Not everyone has lots of free time or the opportunity to work on open source so it’s understandable.
However as maintainers, we can do our part to lower any barriers (whether it be code, feature requests, or discussion) in being a part of our project’s community (this is the main reason to move back to github issues). Gregor did a great talk about reaching out, making contributing fun, and keeping contributing at EmpireJS.
Shout out to the Angular team and especially Igor Minar (who also reached out to send me a t-shirt!), Caitlin Potter, and Pete Bacon Darwin. Everyone was quick to respond to the (many) changes and were willing to help me through the PR process. Even though all I did was change whitespace, I learned more about the tools used (npm, grunt, etc). Even manually changing hundreds of files and thousands of lines of code for spaces got me to see parts of the codebase I wouldn’t have looked at otherwise.
When choosing a project to contribute to, I think an important thing is context. You aren’t willing to look into the issues/pull requests because you don’t have context initially. I either got bored/overwhelmed at the issues being discussed or new features because I never used it myself or encountered that bug. That’s why I and others would recommend contributing to projects you use in work/side projects or ones where you have a passion to learn more about. A lot of the work is like tending to a garden.
I would seem that only maintainers have the context to be able to look at every single issue/PR. And that’s only when a project is small (in codebase, scope, and reach in the community). After some people decide to use it, it’s gets out of control. Many maintainers aren’t always familiar with all parts of the codebase, and it can be impossible to track all that’s going on.
Of course, even cooler than being able to contribute to open source was… getting an e-mail from Joel Kemp (some months later) about whether I’d like to join him and Mike Sherov at Behance since I was doing great work on JSCS with them. I was really flattered and it sounded amazing but I really wasn’t sure I wanted to move from my home state to New York. I was naive enough a few years back to think that I had to go to Silicon Valley and apply to some big companies there and didn’t really think about other locations.
Thanks to the discussions/prayers with my parents, friends, and church I decided to at least give the interview a try, and later accept the offer. I am certainly privileged enough to be able to work on open source in my free time and crazily enough I even got a job through it.
I felt like joining would give me a better opportunity to be more involved in the community and to level up my skills at a place that cared a lot about good engineering as well as design. In addition, I found out about the awesome borojs community there!
At the start of my open source journey, it made sense that I just wanted to contribute. But later with more of a maintainer mindset, I wondered why we couldn’t merge the projects? I think we all had the same idea, and wanted to prevent further burnout. After just a month or two of discussions we agreed on the logistics of the merge, how to incorporate the best parts of JSCS, and our plan moving forward. I’m really glad to see such positive response from the community as a result.
Of course I need to give a shoutout to Sebastian McKenzie for his inspiring work on Babel. I definitely remember really wishing to help out after only just hearing about the project. And I don’t believe I even knew ES6 was a thing before that.
For a while, I had no idea what the issues were talking about. I think I kept watching/un-watching the repo since the notifications would pile up and I had no idea what the bugs or code was talking about.
Instead, I helped out with https://github.com/babel/babel-eslint in the meantime while I got acquainted with the codebase.
A huge thanks to the rest of the Babel team (we should setup an info page): James Kyle, Logan Smyth, Amjad Masad, Jesse McCarthy. I still don’t know how it’s possible we are maintaining this huge project. It can get pretty frustrating at times for various reasons (drowning in a sea of issues/complaints, burnout, work, life), but its great to be able to help out with a project that we can use in our own projects, at work, and by others. I really appreciate the work Nadia Eghbal and others are doing on sustainable OSS and trying to bring these issues to light.
Recently, we’ve had some new collaborators: Daniel Tschinder (who has been making amazing work on babylon fixes and currently all the work done for us to move back to github issues), and kangax/Boopathi Rajaa for the to-be-released minifier.
I still can’t believe that somehow I became the maintainer?
So, for those that continue to have fears in getting started in open source, I want to say I started out feeling the same thing. Hope this sheds some light on how I got started, my motivations, and why I continue. I think ultimately it’s about community, not code.