Most projects are humble enough to document their problems — bugs, missing features, unwritten documentation, and more — in a bug tracker. To contribute, all you have to do is find something to work on, build and share your improvement, and convince the maintainer to include it.
You don’t have to be a programmer. Lots of projects urgently need design, writing, translation, testing, or marketing help. And if you are a programmer, you’ll find there’s plenty to do.
Let’s start at the beginning.
Find something to work on
Some bugs in the volunteer opportunity finder are labeled as “bite-size”. This means that a project maintainer has marked this bug as good for newcomers. They’re a great way to learn a project’s code or the open source process in general.
Go on, try it and browse for a while. I’ll wait right here.
(If you want to work on a project outside of our index, find their bug tracker and try to find something you can work on.)
Download the source code and make your changes
Now open up your editor and make your improvements. The project may have a README file that explains things you need to know.
Once you’ve created a new version of the material, don’t forget to test it out. If it’s documentation, make sure you used the right syntax for formatting it. Many projects use a tool to generate HTML pages out of the documentation; if you changed documentation, run that tool and make sure your improvements look OK. Projects also often include tests that can automatically verify that the program still works. Typically, the README file will tell you how to check whether your new code passes all the tests.
Share your work as a patch
If you downloaded the source with a version control tool, look for a feature called “diff” that outputs a patch. Usually it’s as simple as running a command like this:
git diff > filename
Then filename contains your changes.
(If you didn’t use a version control tool, check out Stephen Jungels’ quick guide to using diff and patch.)
Once you have a patch file, write a comment on the bug explaining what you’ve done. It’s okay to write a long comment — details are great. Then attach the patch file to the bug report.
Convince the maintainer to include your work
If you choose a bug that’s labeled as bite-sized, you’re more likely to get feedback quickly. That’s for two reasons: The bug is small, so the maintainer isn’t afraid to read a long patch, and the project maintainer is probably especially open to new contributions.
As the maintainer gets to know your work, she or he might allow you to skip the whole permission process entirely, and “commit” or “push” directly to the code.