New Contributors To Open Source, Please Blog More
Shubheksha Jalan Sep 14 '16
I wrote this post a while back to help newbie contributors realize that they’re not alone in feeling lost & dejected when they don’t understand a huge code base or how different modules interact with one another. There are a lot of us in the same boat. And it’s okay to be there. So many people reached out to me telling me that they were motivated by my post to start or resume contributing. A few maintainers were also encouraged to go back and review some pull requests after reading it. I couldn’t have asked for a better response!
After a fair amount of deliberation, I reached the conclusion that the main reason for such a reaction is that the dialogue has been one-sided for a very long time. There have been a lot of posts by maintainers on how to get new contributors involved in their projects & all the things they can do to make their project beginner-friendly from tagging of issues to setting clear contribution guidelines, etc., tons of guides on how to start contributing, questions on Quora and other platforms, but there aren’t as many posts by newcomers on how it pans out when they start to contribute. I’ve gone through many of those guides myself but it isn’t as helpful as a fellow newbie contributor’s firsthand experience with a project they started contributing to, the path they followed, what they expected & what came out of it. It’s difficult to strike a balance when only one party is communicating.
Thus, I want to encourage all new contributors to document their experience if they wish to help us establish this balance. I assure you it’s worth your time & patience. While writing, you can’t gloss over the details, you can’t brush what you think is not required under the carpet. It forces you to perceive things as they are & not how you think they’re & put them into perspective. It also helps you realize where you started & how far you’ve come. Write to learn better.
I know a lot of folks will be thinking — I don’t know enough to write about a particular topic. You don’t have to be an expert at a topic to write about it. Write what you know. If you’re wrong, someone will point that out & you get to fill in the gaps in your knowledge. It’s a win-win situation. Believe me, nothing feels better than knowing something you wrote helped a person who is struggling, be it with a technical topic, motivation or inspiration. Even if it doesn’t help a lot of people, it’ll certainly help you at the end of the day.
I was scared of all the things I mentioned above & I’ve been a couple of drafts piled up, waiting to be published for the fear that they’re not good enough just yet — they can be better, more polished, more technical. I’ve been surfing the internet for inspiration to write better or even just find topics that I feel qualified enough to write about. That’s when I stumbled across a post — Write An Excellent Programming Blog by A. Jesse Jiryu Davis. I keep going back to it & re-reading it if I feel like I don’t have a topic or feel ill-qualified enough to write about what I know. Another place I look for inspiration all the time is Julia Evans’ blog — her posts are short, simple, to the point & a joy to read & still she manages to make you learn something interesting with almost every post. I occasionally end up on Joel Spolsky’sJoel On Software & Jeff Atwood’s blog. They’ve some high quality content on all sorts of things related to tech & I like visiting them once in a while. If you’ve a favorite programming blog you visit often/regularly, please let me know in the comments. :)
Look around for inspiration, I am sure you’ll find lots of it since a lot of quality articles on various things related to tech get published everyday. If you don’t feel confident enough to start writing on technical topics, it’s okay, you’ll get there slowly & steadily — start with just documenting your journey :
- How you got involved with the organisation you’re contributing to
- What kind of community they have & how welcoming it is for new contributors
- The project you chose to work with & what went into deciding the same
- How difficult was it to set up the local development environment, where you got stuck & how you crossed that hurdle
- How you found the first issue to work on
- If you had a mentor assigned, how was your experience working with him/her & the kind of help you received
- What you expected open source to be like versus how it actually turned out to be
- Any advice you’d like to give to fellow newbie contributors once you’ve gotten your feet sufficiently wet
- How to behave & what kind of questions to ask in a organisation’s IRCchannel or Gitter room
These are just some topics I can think of off the top of my head. You don’t have to write daily or weekly or follow a strict time-bound schedule. Write when you feel like you feel you’ve something worth telling, something that can help others & in turn help you too, be it a small victory or a large contribution.
Slowly & steadily, as you gain more experience, you can begin to write on technical topics depending on your skill set. It can be something you’ve been working on or with for a significant amount of time or your journey to acquire a new language/framework/library. At this point, you might wonder, too much has been written on that topic already, what more can I possibly add to it that hasn’t already been said? It doesn’t matter how much has been written & by whom, it never stopped anyone from writing another article from their very own viewpoint, based on their understanding. Everything you write has your very own perspective which might greatly differ from another person’s despite the same topic. It’s all in the details — how you break a topic down, how you approach & understand it. So don’t let the fact that there is too much already written about a particular topic deter you from writing your own.
Therefore, I want you to write & extensively document your experience extensively for you to learn better, become a better developer & possibly help a lost, intimidated newbie contributor in the future searching the internet frantically to find their way around the vast world of open source software.
P.S.- If you’ve any additional ideas, I’d like to know them & possibly add to this post as well. :)
This article was originally published on Medium.
As a react developer, I believe that everyone who is working on a react project must develop all the components separately for taking advantage of that components philosophy behind this amazing front-end framework.