Slides available on SlideShare (I need to fix an embedding bug on the blog, oops).

Most of you know what Open Source Software is and hopefully think it's awesome. Have you ever contributed a patch? A translation? A bug report? Would you like to do any of this?

(If this is the first time you hear the term, roughly open-source is software for which the source code is freely available, that can be redistributed and modified.)

This talk is for people who like open-source and would like to give back, but are not sure where to start, or if they're smart enough or if their skills would be valued.

And my goal is to encourage you to make the jump from 0 to 1 contribution (or one more!) :)

Because I'm a software developer, this talk focuses a bit more on code contributions. (Don't think this means other types of contributions aren't needed, help is always welcome everywhere!) For many years, I wasn't strongly attached to any particular project but got patches in here and there (Sugar, Gnome, Django...) Nowadays you're more likely to find me in the land of OpenStack.

First, let's clarify something important: you don't need to be a genius to contribute. It's not as difficult as it may initially appear. All skill levels and all types of skills are needed and appreciated.

As to where to start, first I'm going to tell you about a wonderful shortcut, and then I'll go through how it usually works.

OpenHatch is an organisation whose mission statement is: "helping newcomers find their way into free software projects." They aim to bring together all the simple bugs, help requests and help wanted, documentation, all sorted by project and by language. It's a great way to get started.

Now, the way it usually works. When you're looking to contribute to a project, you should first look around for contributor guidelines. If a project has contributor guidelines, it's an excellent sign. It means that they care and that they've thought about it, which is very important when it comes to first contributions.

Read them! You don't have to remember it all. It will give you a sense of direction and an idea of what matters for the project, what to watch out for too (patch format, coding conventions, where/who to talk to, etc.)

As an example, here's a screenshot of the Gnome documentation for new contributors. There's a lot in there! They care a lot about welcoming new people.

In any case, whether a project has contributor guidelines or not, the workflow tends to be the same. Read the guidelines if they exist :) From then on, look at the bug tracker to find something that you'd be interested in working on. Now that you know which part of the project you will be working on, build it. Find the bug, fix it and submit your patch!

I'm going to be using the first contribution I made to Gnome as an example throughout this presentation. The Gnome folks are a very friendly community, and have a special tags for bugs that are good for newcomers called "gnome-love". In other projects this may be called "easy picking", "bite-sized", "low hanging fruit", etc... It should be mentioned in the contributor guidelines.

Look at the list of bugs tagged with that keyword and find one you like that is easy. (Avoid choosing a big feature as a first contribution. You need to earn some trust first, as well as pick up the project technical and cultural conventions.)

Once you know what you will be working on, it's time to build the software. This is very important, you will be learning new tools, perhaps even new languages. For instance I chose a bug from gnome-terminal which is written in C and uses autotools, which I wasn't very familiar with. This is why it's important to select a small first bug, because you have a lot more to learn to get there.

If you can't find instructions to build the software, you have a couple of solutions. Sometimes a mentor comes together with the "easy pickings" tag, or the community has its own mentorship program. You can also go back to the magical portal mentioned earlier, OpenHatch, where "training missions" are available to get people up to speed with some of tools commonly used in open-source.

People forget they had to learn all this in the first place. Don't sweat it. This is a stepping stone.

Once you have a working build, it's time to reproduce the bug, find it and fix it! If you're lucky, the location of the bug may have been mentioned in the bug report. As said earlier, the person who marked the bug as an easy task may be willing to help mentor you through it. It's ok to ask for help if you're having trouble.

As an example of a first task, I was lucky, and I indeed picked a very simple one - changing a colour in the gnome terminal!

Once your fix is ready and tested (you have rebuilt the software with your fix in it), it's time to submit the patch. Now is a good time to refer yourselves to the contributor guidelines once again, it will be useful to find out what your patch should look like (coding guidelines), what command you should use to create the patch, and where you should send it. If there are no such instructions, the safest path is to attach the patch to the bug report in the tracker.

And... congratulations! You've made your first contribution to open-source. Take the time to pat yourself in the back and be proud, you deserve it.

The process isn't quite finished yet: the next step is to wait. Perhaps your patch will be accepted since it's a small contribution. It's just as likely you might get some feedback on how to improve it - everybody wants to make their project better so don't take it personally, take the feedback on-board and resubmit the patch. If your patch gets lost in the ether, you should consider pinging the component or project maintainer.

In my case... I was lucky :) The patch was accepted and merged in the main codebase about an hour later!

If the only answer you get is silence - don't take it personally, really. People want you to stay, a healthy project know they need new people in order to stay alive. Open-source projects are always short in resources.

If the people involved in the project you contributed to have a bad attitude, don't be discouraged. And don't stick around either, there are a ton of cool, useful projects with friendly communities who could use your contributions. Life's too short.

If you've done your research, read the guidelines, there won't be any dragons. Most people are very nice! It's great to become part of a community that cares about creating the most awesome project they can.

And as a closing word before opening for questions: remember OpenHatch.org. They are people dedicated to helping newcomers find their way.