So you want to write some code?  Great!  We can't do it all ourselves, so patches are welcomed and encouraged.  But, before you jump into the code and submit your modifications, there are few things you can do to increase the likelihood that your patch will be easily accepted.

• e-mail the discussion list with your idea first.  To keep down on bloat, we only add needed features.  Sure, it would be great if it could make you breakfast, but chances are another tool could do it better.
• Check the roadmap.  We've got a list of features and fixes that the tools already need but we haven't coded yet.  The roadmap is almost our plea for help.
• Follow the Amended Indian Hill C Style Guide.  We're picky about what the code looks like, and will reject a patch if it's sloppy.
• Update everything.  For a patch to be complete, it must update all associated man pages, usages and comments.  Everyone knows that code is the fun part, but the other bits have to be done too.
• Understand the license.  All code is released under the same license.  If you don't like it, you shouldn't submit a patch.

The best way to make a patch is to create it against the current CVS repository.  This helps guarantee the patch will work with the current code and makes life easier for the developers.  

1. Get a copy of the source code from CVS
2. Make your changes
3. Compile, test, fix bugs, compile, test...
4. Run cvs diff -u > /path/to/file.patch
5. Review patch for expected changes

Now that you have your patch, send it to the development mail list.  Be sure to include a summary of what the patch does, what code was changed, any known issues it might have and what version of the code the patch is against.  As developers and maintainers test and give feedback on the patch, be ready to respond, incorporate changes and create new patches.

Once its accepted, you can sleep better knowing that you've contributed to the project.