you get involved with a project by getting their source code. if you install via compiling the source you are all set, otherwise you probly have to find their home page. you then start reading the readme, and any other text files of that sort in the source code top directory, these will often explain things you may need to know at a latter point. then start looking at the source itself. at this point it might help if you know the developers, and expect this to take a significant amount of time. a project of any size will most likely not have a self-evident flow when you first look at it, the feel of the source will only come to you with time and expirience with it.
cvs helps alot. its a VERY powerful tool, and ment far more for developers than for people submitting patches, but the basic options are something you will be using. you'll need the commands cvs login cvs checkout cvs update and cvs diff
you can use cvs -H <command> ie cvs -H diff to get options on using a specific command. you will also either have to use the -d flag BEFORE the command or set the CVSROOT environment variable ie cvs -d :pserver:cvs.gaim.sf.net:/cvsroot/gaim checkout gaim will get you the copy of the gaim source code if you have previously run cvs login with the same -d flag contents.
the advantage to cvs for you, is that you are then working with the same code the developers are working with, instead of a body of code that is older, has some bugs fixed, some bugs introduced, some features removed, some features introuduced, so on. working with the same source code gives you a better chance of having your patch accepted.
you'll use the cvs diff command or the patch command to generate a patch. a patch is a list of differences between 2 versions of the same file(s). the patch command is also used to apply a patch. when you submit a patch, be it for a bug fix or a new feature, the developer(s) will read your patch to attempt to identify if its the correct fix/correct way to implement a new feature. keep in mind that some projects have style guidelines, for instance gaim does not allow gtk in some parts of the code. also keep in mind that while a given piece of code might fix your problem, it might introduce a problem for users in difference circumstances, so developers are at times very careful accepting patches, especially before they have a chance to get to know you and evaluate the quality of your work for themseleves. if two people submit the same patch, any number of things can happen, the developer might like the way one of you fixed the issue mroe than the other, or [s]he might simple use which ever was looked at first.
sometimes developers are able to get to your patch, evaluate it, and give you some feedback within a short period of time (a week or two), but that's the ideal. in real life, developers are working in their free time, are often over-worked and for good reasons or bad ones, feel under-appreciated. as a result, looking at patches sometimes gets delayed, so be patient with your developer.