WebKit and GStreamer. Now that I follow these rules, I generally find it relatively easy to get changes into open source projects.
Note: This guide is not about learning to program. If that's what you're looking for, I recommend this set of projects, which is similar to what a class would give you. Or just take a class.
Before you even talk to the maintainers, start thinking about if your patch can be broken down into multiple atomic patches. The goal of this is to:
Don't take this to mean that you should try to submit incomplete patches — every patch should do something meaningful and work perfectly. What this means is that you should try to make each meaningful, working change into a separate patch.
If you're looking at a project that implements a spec, and you want to implement a newer version of the spec, you should generally try to implement each feature separately. You might even be able to break individual features into multiple patches in some cases.
For example, if you wanted to implement an HTTP/2 feature in a project that currently only supports HTTP 1.1, you could break it down as:
If you're proposing a patch to a "dead" project or a project that isn't the maintainer's primary interest (like someone's website), it can be less work for them if they only have to do one review session. Talk to them to find out if they'd prefer one big patch or multiple small ones (see step 2).
The most important thing you can do when contributing to open source is to communicate with other members of the community. You don't want to write an entire patch and then find out that someone else was already working on it and doesn't need your help, or that your patch implements things in an unacceptable way.
So, figure out how to contact the maintainers and tell them what you plan to do. There are several ways to contact project maintainers, including:
If they have an issue tracker and it already has the things you want to implement, just leave a comment on each one saying:
Otherwise, create one or more issues with the same information. Try to match the project's bug-tracking style. Large projects usually want one super-issue for large features ("Implement TLS 1.2") and many sub-issues ("Implement the TLS_RSA_WITH_AES_128_CBC_SHA cipher"). Smaller projects frequently want one issue with multiple pull-requests. Try to guess what they'd prefer and do that. If you think they will want super-issues, start by making that one and ask if you should create sub-issues (unless it's obvious that you should).
Take any feedback they give you into account. This might save you a lot of work.
This part is up to you, but there are a few things you should consider while you do it:
git rebase. Your patch will need to apply to the most up-to-date version of the code when you submit it. Many patches have been lost because they no-longer apply cleanly, and the maintainers don't have time to fix them.
Now that you have a nice atomic patch that passes tests, doesn't have superfluous changes, and applies cleanly to upstream:
If you've followed the other three steps, this one should go quickly, since the maintainers already know what you're doing and approve of the general approach.
You did it! Your coworkers and/or open-source-using friends will think you're a hero. Hopefully they'll never figure out how easy it is.