This document tells you how you can participate in any OpenSource project on your level and even eventually even become one of its most valued members. At least it will show you several ways how you can give something back to the OpenSource community.
To participate in an OpenSource project almost no prerequisites are necessary as long as one is willing to spend the time to learn it. Of course all OpenSource activities are communicated in English, therefore a minimal understanding is needed. Just keep in mind many of the OpenSource developer and the vast majority of the OpenSource users aren't native English speakers either, so don't fear anything. If you want to communicate anything but you don't feel sure, you may simply look for a good spell checker. Think even I do usually check everything which I put up for public review.
The second prerequisites are spare time. Don't expect to find someone who's paying you for your hobbies, not even if it's called OpenSource. First plan how much time you are able to spend on a regular basis. You soon will discover that you never will have enough time to do everything you want to do. So better make an estimate how many hours per week you can spent without sacrifying your normal life. Then you can set your goals accordingly. Try to finish one task first before you start another one. This will give you much more pleasure than lots of half finished unusable work.
Well that's everything you need to start, all else you will acquire during your participation. Of course depending on the goals you set yourself it will need a lot of work but I can guarantee it will be a fantastic experience you'll miss if you haven't tried. Again I want to remind you the fun is much higher when you choose something you can bring to success yourself. Always try to do as much as you can but don't hesitant to ask in the appropriate place for help if you get stuck. As long as others see your doing something usable they'll likely help you further.
If you are accustomed to participate in OpenSource projects just read the next paragraph.
If not, start with subscribing to the users mailing list. You'll soon find out what others do and where you might start helping. Finally just write a message in the mailing lists asking what you could do.
The following groups give hints what you could do with your knowledge and the amount of your participation:
Any user, no prerequisites except English and willingness to take over some work.
Translators, has to know English and be fluent in the translated languages.
Testers, know how it should be.
Developers, knows to code in some respect.
Managers, do all of the above points plus
Fans, like this project, this product or just the idea ;-)
Don't mistake testing from just using, testing means you're looking for a clearly marked part to check if everything behaves as it should. This means you first have to make a plan what you want to check and under which circumstances. Without a plan or a checklist your test is nothing more than just using it with keeping an eye on abnormal behavior. Any test means to create first a checklist with the following points:
Description of the test: A good description shows what you want to accomplish. That means a single sentence might be enough if it describes the test accurate. Otherwise the description has to be longer.
List of prerequisites: This is very important since other might not have the same system and therefore can't produce the same results. The prerequisites might not always be needed, at least they describe the circumstances your test where done.
Test points: Depends on the tests you want to do. Keep each point as unique as possible.
Results: These always list the difference to the expected behavior.
Conclusion/Suggestions: What ever your tests produce. This might lead to an appropriate bug report.
Documentation is the Achilles heel of any OpenSource project. Documentation is seldom done in the right fashion, mostly missing, sometimes too spares, sometimes too detailed. The problem is documentation is done by someone with lot of inside knowledge but needed by others without. So creating any good docs involves always two parties, the one who knows and the one who doesn't.
The best way to create docs is when developers create some preliminaries outlining the overall structure. Then users' looking into docs starts asking questions to solve any miss understandings. Now if a user gets a useful answer it should be his obligation that the relevant parts in the docs are reworked accordingly. After all he got an answer and storing this answer in the right place shouldn't be too difficult. There's always the chance that he need the answer a second time, happily finding it in the docs then. Changes to the docs might simply send to the mailing list or submitted as a bug report.
In case a project provides a wiki anyone can change the docs himself. This is by far the simplest way as long as the wiki allows finding anything. Again before users can start adding anything to the wiki the overall structure has to be laid out.
Don't forget docs are from users for users, if you can relieve a developer from it he has more time to develop the project further. In successful OpenSource project it's essential for everyone to make life for the other easier.
That doesn't mean developers don't have to care for documentation. Contrary they have to care for that a user easily can locate an answer for his questions. I know this isn't easy but as long as you can't provide a solution you will be asked the same questions all the time. Each time a user asks something again and again it's a clear sign that this info correctly documented.
The web site is the first place to make a project known to a wider audience. It is the starting point for anything done as well as to get more information. The web site is the first advertising action of any OpenSource project. Unless you find a distributor of your project it will most likely be the only one.
The web site gives anyone who is stumbling across your project the first impression. It's important to have an accurate description on the best place of the first page. Also it's a must to show that the project is still advancing. It's a good idea to have the web site constantly updated. A single date, which links to the latest news or to the updated status, is sufficient.
Keeping a web site updated draws some developer efforts which can't be used otherwise for project development. With some small effort you can take over rather much of this work. All you need is a little HTML knowledge which is perfectly provided in selfhtml. BTW updating someone's project web pages is a good way to learn HTML.
Even easier work can be done to relieve developers, i.e. nice screenshots, icons, pictures, etc. Just ask in the mailing lists what's needed.
Fixing bugs is the best way to get any knowledge about the internals of a project and to start learning anything. It has a steep learning curve but not as much as it seems from the beginning. If you can't figure out what's going on within a bug, it might be too difficult for your current knowledge, just try some others. There are always some you're able to fix. Concentrate on the bugs which have a simple visible effect on the screen, i.e. a typing mistake, a miss alignment, etc. Working this way you'll be able to tackle the difficult bugs as well.
When you aren't able to fix a bug, consider if you find out something more. Then it's a good idea to update the bug report accordingly so others don't have to go again through all the steps you've done.
Preparation for any bug fixing means to skim through the sources in advance. This is essential to find the relevant breakpoint so debugging can be done efficiently. Source browsing can be a rather boring task especially if the original author didn't care for readability. Therefore some opt for just the trial-and-error method which sometimes produces astonishing results. Still you may ask the author if you can improve the readability.
A prerequisite for debugging is of course the base knowledge of the used programming language but amazingly often base knowledge is just enough. When ever the meaning of a statement isn't fully grasp the results in the debugger gives enough clues. So if a statement isn't understand during source browsing, analyzing the statement with a debugger will do. Sometimes it's just fun to step through others code and will give ideas one would have never thought of.
A very important prerequisite is the knowledge of a debugger (GDB on Linux). Contrary to the language knowledge the better the debugger is known the better debugging is possible. There is no way around to learn to handle a debugger and use it at best.
A very important aspect of bug fixing is to prove that this fix not only fixes the bug but also that it is the correct one. Also fixes have to be analyzed of any negative side effects, i.e. if everything else behaves unchanged. It's a good idea to use a fixed application for some time before a fix is submitted.
Don't under estimate the work for the creation of a good description of the fix, others have to follow your reasoning. Otherwise you will be confronted with all kind of questions. Also a good description will show that you have analyzed the bug deeply and it will much faster be accepted.
Creating a patch is not much different than bug fixing except it mostly means to create something new. This might just be a small enhancement for some annoyances but it may also mean complete new features. Patches are usually much bigger the bug fixes.
Since the impact of patches is much greater than bug fixes, they have to be tested and described much better. It's a good idea to add a test sample to your patch if the patch is rather large. Also it might need some documentation, don't underestimate this fact. When ever a patch is check for acceptance the completeness will be a big factor.
Any patch has to conform to the guidelines a project has set. This is needed to fit your code within others. Nothing is worse than always have to switch between different styles inside the same code. If your project doesn't set any guidelines have a look at wyoGuide to get hints and ideas.