FLOSS projects : How and where can I start contributing?

Question

I'm new to the open source community. I've always wanted to contribute to successful existing open source projects. I thought that contribution to good open source projects was meant only for experienced great programmers. Since there is an open source community on Stack Exchange now, I thought I would ask here.

1. How can someone new to the open source community (like me) start?

2. How does the contribution flow work in open source projects? (Like first maybe you monitor activities in that open source community, then read through the bugs list or contribute to documentation, etc. I don't know, I'm just speculating.)

Answer 1

Where can I start contributing?

There are two obvious stages to this: pick a language, pick a project.

Pick a language

You should pick a language with which you are familiar and proficient. I'd advise not trying to contribute to projects in languages you're not that great in - yes, it is a good opportunity to improve your skills in that language, but it's also a good way to annoy the developers because you're doing things in a way that the language could do much better. A good example of this is Python:

some_list = ["a", "b", "c"]
if hasattr(some_list, "a"):

This seems to be correct to many new in the language: the documentation suggests that hasattr returns true if the given list has the given attribute. However, it won't work as expected, and could actually be done in a much more 'Pythonic' fashion:

some_list = ["a", "b", "c"]
if "a" in some_list:

Moral of the story: pick a language you're good at, so you don't have to worry about your coding style or practices being the cause of your pull requests getting rejected.

Pick a project

Now you pick a project, written in your chosen language, that you want to contribute to. If you've had some exposure to the language, you may already have come across useful utilities or tools that you use that are open-source: these are good choices because you'll be motivated to contribute well.

You should always pick a project which interests you. If you're not interested in crunching data, don't pick a graphing library. If machine learning gets you going, try to find something in that area. Maybe you can even contribute to a project you're already using.

A good resource for finding projects if you're stuck is Code Triage, which lists repositories on GitHub by the number of open issues they have. Pick your language, pick an interesting project, pick an issue and try to solve it.

What's the contribution flow?

This really depends what you're good at, though there are some givens. You should always start by familiarising yourself with the project: read the documentation, read the codebase. If the hosting supports it, you should clone the repository and build the software on your local machine, and have a play around with the code to figure out what each part does.

Once you're familiar, you can choose what you want to do. If you're a technical writer, writing documentation is probably a good choice for you. If you hate writing long documents, but you're good at programming, pick an issue and try to fix it.

Whatever you do, make your changes in a fork of the project's repository somewhere you control. Test them (see Whose responsibility is it to test contributions? for information about who does what testing) and make sure everything works. Make sure your code style conforms to that of the project: developers aren't going to be happy with ten thousand different styles in their project because they've got lots of pull requests. Make sure you've read any contributing information the project has. If you've conformed to everything, you can submit a pull request to the project's developers, who will review your changes.

Expect rejection.

You're not perfect and neither is your code; the project developers may well find some issues with it or some style point they don't like. It's your work, so it's your responsibility to fix these: monitor the feedback on your pull request, and use it to change anything they ask you to. When that's done, you can resubmit your pull request and have it merged. Wash, rinse, repeat.

Answer 2

1. How and where should a newbie like me start?

Pick a project you use, and that you think can be improved (a bug needs fixing, there is a feature that you would like to see added). Make sure your contribution is small and focused.

2. How does the contribution flow works in open source projects? (Like first maybe you monitor activities in that open source community, then read through the bugs list or contribute to documentation, etc. I don't know, I'm just speculating.)

You're on the right track. The details depend on the project. Drupal, for instance, offers a detailed description of novice workflow. Look for similar guidelines in whatever project you're interested in contributing to.

Answer 3

The first thing you should do is select a project. A good place to start would probably be a project you already use, or are at least passionate about.

Second, I'd do some lurking - subscribe to the mailing list(s), and read a bit so you get the "vibe" of the community and get an initial feeling of what's acceptable and what's not, what kind of patches are welcome, etc. Once you get comfortable with that, start participating - answer simple questions you feel you understand fully, share your opinion on open questions, etc.

Now you're ready to start getting your feet wet. Don't expect your first contribution to be re-writing the entire thing from scratch. Baby steps is the way do to it.
Before starting anything, read the submission guide (e.g., here's git's, just as an example) and the coding standards (again, git's). Following them will (hopefully) prevent your patches from just being out-right ignored, not to mention it's just common courtesy. The more "outgoing" projects have an open task list, and the really outgoing ones have it broken down by skill/knowledge levels. If your choice project doesn't have such a list, it's bug/issue tracker is a good place to start. (Simple) bugs are usually well scoped, and even if the solution isn't always obvious, the requirements usually are.

And most importantly - be ready for feedback. Very few patches get accepted in their first iteration, and although the feedback you get may be worded harshly, remember to take it as feedback on the patch ("this isn't good enough to be merged yet"), and not personally.

Answer 4

Before you start contributing to an open source project make sure doing so is something you want to do and aren't doing because you think you need to.

Andre Arko has three questions you should answer before diving into an open source project: https://www.cloudcity.io/blog/2017/01/25/is-contributing-to-open-source-right-for-you/

If answering the questions, open source is a fit for you, dive into Andre's 15 minute a day plan for going from newbie to core contributor on an open source project: http://andre.arko.net/2016/11/12/how-to-contribute-to-open-source/