Contributions are always welcome. The preferred way to create a pull request against the GitHub repository. Remember that pull requests for documentation or additional test cases are just as valuable as code patches.

Rules for submitting pull requests

These rules are intended to reduce the effort that the maintainers need to do when accepting a pull request. If the pull request requires too much effort to "clean up" before being merged then it will likely be rejected. Remember that everyone working on this project is volunteering their time so lets be considerate.

• Make sure the code follows the coding conventions already in use. Refer to the link above to see the coding conventions that we are using here. We use checkstyle to enforce many of the coding standards (some things like good naming can't be easily checked with a tool, but we check as much as we can automatically). The maven build should perform these checks for you.
• Make sure the new code has automated unit tests written for JUnit. No code will get merged without tests. Whenever possible, tests classes should extend WebDriverTestCase.
• If you are fixing a bug but not adding new functionality then we still require tests that would fail with the old behavior.
• All existing unit tests must pass.
• All files must be copyright Gargoyle Software Inc. and must be licensed under the same license as the rest of the project - currently an Apache style one. This is required so that we can make sweeping changes such as the license change that we already did (from LGPL to Apache style).
• All non-private methods must have full javadoc before we put out a release. Putting javadoc on private methods is a good practice as well but isn't required. If you make changes to a given file then you are expected to add an author tag at the top of the file. @author tags are written in chronological order with the original author at the top. Refer to How to Write JavaDoc for more specific information on javadoc.

IMPORTANT: Pull requests without tests will be rejected. Occasionally one of the committers will have the time to write the tests for you but this is rare. If you are not sure how to write a test for a given situation then ask on the developer mailing list.

Additional documentation or code samples are always appreciated. We're focused on writing code and documentation often gets neglected.