How to start contributing to open source as a junior or newbie?

jen chan on September 22, 2018

What are some open source projects juniors can contribute to? Please share some projects you know of that are open to junior contributions/pull ... [Read Full]
 

As a senior I started not by writing code, but doing issues maintenance, finding duplicates and related bugs.
Helping devs to reproduce bugs.
You can write documentation, unit tests.
Doing all these you will get familiar with the OSS practice, the project and its mainteners. You will do PR in no time after this.

 

I returned with the last 2 concrete examples:

github.com/golang/tour/issues/541 - lead to a problem in another server actually, and it was one that I couldn't find or fix anyway, I don't have that deep knowledge of the product, but putting in time and gathering enough data helped other devs to find the problem quicker

github.com/golang/tour/issues/507 - closing over 100 issues helped a lot with the issues management, is like removing dead code

Bottom line is that choose a project you love, and start contributing with what you can, when you can, things will evolve naturally. There is no pressure, no material gain, is all about love for software.

 

I just keep other Devs busy getting them to help me fix all my bugs I earned just learning new projects...my woops...and honestly need and appreciate all the help...I'm beginning

 

Not sure if you’ve seen it or not, but CodeTriage.com is designed to get people involved through an “issues first” approach.

 

Thanks for offering the examples! I am going to look and ape :D

I agree bug reproduction and unit tests are a great place to start. My last gig was in support so I'm familiar with the repro side; my life's wish is to see/get to the end of a problem. :)

 

I started because I found a couple of critical bugs in a query language parser I was trying to use. I think it made a good introduction -- but I still had to get over the same instinctive feeling of "oh shit what if this is actually garbage and I'm wasting the maintainers' time" on my own and stick my neck out. If you can start with something straightforward that's probably for the better, but it really does just come down to putting your work out there and seeing what other people have to say about it.

Also: this may not apply so much to larger projects but if you drop a pull request on a smaller repository you're probably going to make the maintainer's day, whether or not it needs more work before it can be integrated. Seriously! You're telling someone you care enough about their work to help make it even better! Who wouldn't deal with a little back & forth to iron out details for that?

Documentation is easy but there's no reason you shouldn't go for code if you feel up to it. Many projects tag "good first issues" or the like; I've had a couple small feature additions there for a while. If either of those strikes your fancy I can work with you on hammering a pull request into shape.

And remember:

On the internet, nobody knows you're a dog

Junior is what you make it.

 

I love your comments. haha

You're right, a lot of this comes with practice. Documentation is a strength of mine but that's really copping out if I'm looking for feedback on coding.

And good point about dropping PRs into lower-traffic/small repos. I had not thought about that. I'll be sure to ask for pointers when I start sending them. Currently in a crunch trying to kludge together a small site.

 

I'm in a junior role at the moment. At my job, writing code does not depend on seniority or hierarchy, but on need and ability.

I have written code since my first week, and some of the changes I have made to the codebase had a positive impact. I think writing code should be done by everyone regardless of position in company.

As to open source projects, I'm lucky to have a team that has actively encouraged me to contribute to the open source tools that we use. My advice is find a project you like or have used in the past, try a library perhaps, something that is not overly popular (e.g don't go straight for Kubernetes/React) and get familiar with the codebase and use cases. Track the issues or create a PR based on something you would need out of the project if you can't find an issue. My biggest fear was the community, trust me, there are some people with bad attitudes but the open source community is a bliss to work with, don't be afraid to ask questions or get involved in projects! Good luck.

 

This is very relieving to know there are places that also trust and encourage juniors to push to production.

"My biggest fear was the community..." I think you've pulled the words out of my mouth!

That is true I should start with a tool/library that I like and use a lot. Duh!

 

I'm glad you're determined to contribute to open source! Trust me, once you see your first PR merged in (where you contribute a fix or a feature) you will feel amazing.

Also, another thing to keep in mind and that I was told when I began my internship for my current company is that it's ok to be confused. A lot of developers are confused as to what the task is, what they need to do, what different parts of a program do etc. This applies to open source projects, once you find a project you're comfortable with, spend some time to read the code base and see how everything ties together, and remember it's ok if it doesn't instantly click! I myself needed a good week to understand the most basic parts of my first project. You can always just open an issue and ask if help is needed, or ask for help in case you need some clarifying!

Right now I'm focusing on platform/core infrastructure, these are two of the projects that I have contributed to and that have very good communities:

  • kube-aws - CLI for K8s clusters in AWS
  • helm/charts - charts for Helm (package manager for Kubernetes)

These might not be your cup of tea but you can take a look around to see what kind of work people put in and what (lesser) known projects look like. If you need any help, give me a shout!

Break a leg on your open source journey!

 

I maintain a couple projects where junior contributors are always welcome.

Viano, a musical toy written in Vue.

SpitScript, a transpiler that turns rap lyrics into JavaScript.

Pros: neither of these is mission-critical for anyone, so the stakes are nice and low, and there's no pressure to make everything perfect.

Cons: neither of these is very important, so you won't get much clout in the open source community by contributing.

Still, if you're looking to get your feet wet, you're welcome to check them out.

 

Hi jen,

some projects have issues clearly marked for newbies or first timers. Some communities are more friendly than others. GitHub has a tag called "good first issue" that many projects use to help newcomers, devto's open source project does as well.

Some good starting points could be GitHub's page for new contributors, the OpenSource guide on how to contribute and CodeTriage which is a website that sends you open issues out of a selection of your favorite projects.

Here on dev.to there are some discussions that might give you more input:

:-)

 

@codemouse92 has an open source project. He actually has lots, and they're extremely nice to newbies. Get him to give you some of his work.

 
 

Thanks for drawing my attention to that! It should serve as good motivation to just put my PR out there... lol

 
 

Check out CodeTriage.com which helps people get involved in any existing OSS project that is hosted on GitHub and has issues enabled.

code of conduct - report abuse