There are a few points to keep in mind when you are trying to get your first code into Compiz Fusion. This page attempts to cover the process of making patches that will be accepted.
Keep them small
Large patches tend to be ignored because it takes a lot of effort to look into them. If you need to alter something in several places, you can do this through several patches. Commit to your local repository often, then submit patches either to a specific product through the bug tracker, or by sending a set of patches to the mail list.
This allows developers with commit access to review each patch separately and approve a subset, instead of having to go over one huge patch and discard the whole thing.
Large patches are also ignored because they are harder to understand, and harder to check for correctness. Even if it is the same sort of issue you are correcting in several places, it is better to split it up (eg. a patch to change a naming convention). Even name changes require someone to actually check the patch for correctness.
Follow the established coding style
Make sure you configure your editor to follow our Coding Style.
Use git patches
git-format-patch is an excellent tool. Use it. It is not an absolute requirement, but you will make things easier for both yourself and the committer. This also ensures that your name is kept as author and keeps your commit messages intact.
This also goes well with the first point of keeping each patch small, as git-format-patch will do the job of splitting it up into smaller patches for you, given that you commit often.
Discuss or inform about large changes prior to submitting a patch
Large patch sets, even when split up, are likely to be ignored if they are not expected.
Either talk with one of the active developers on IRC and make sure they will look at and/or accept your patches, or discuss it on the mailing list in advance. This way you avoid doing work that could go unused, and you avoid putting your fellow developers in a situation where disagreeing with you means you have wasted a considerable amount of time, thus making it harder to disagree with you.
This is doubly true when it comes to subjects that might be somewhat controversial.
Explain your patches and post them
Your commit message should describe each individual commit. When sending in a single patch, this can be done on the bug tracker, which is preferred if the patch is obvious. Otherwise, use the mail list.
If you are sending a bulk of patches, explain the general idea behind the set, then explain each patch if its purpose is not made obvious in the file name. You do not need to explain each patch of a naming convention fix for multiple plugins, for instance.
Development/AcceptablePatches (last edited 2008-03-30 18:34:16 by localhost)