This document enlists a number of rules indended to help your possible contributions to be accepted by the project.

Preparation

Choose the area you would like to contribute into. It could be the issue you have been striked by in production, or some old bug found in the tracker, or some improvement or even new feature your company is interested in. You may also ask the team for directions that are short of working hands.

Search the project issue tracker for the selected topic. This bug could already be fixed in the more recent Firebird versions, or this new feature could already be assigned to some other person. It's also possible that the topic has already been discussed and rejected by the team members. If the topic has not been registered in the tracker yet, proceed with that and indicate your willingness to address the issue.

Development

Investigate the best way to implement the topic. If you are not confident in the chosen solution, don't hesistate to ask for assistance in the appropriate mailing lists. For any major development, it's highly recommended to share your design concepts before starting the actual implementation.

While developing the solution, please follow the existing architecture and coding style. Also, try keeping in mind the possible side effects like cross-platform issues, interacting with other functionality, etc.

Testing

Make sure your changes compile on all the platforms you have access to. It's highly recommended to perform a full rebuild including the boot build phase rather than just recompiling the modified modules.

If the changes affect the SQL language, test the expected behavior using the Firebird ISQL utility. It's also worth downloading the official QA suite and running the existing regression tests.

Submitting

Post a message into the development mailing list with a detailed description of the changes you have made and attach the complete patch (preferrably in the unified diff format). Each submitted patch should correspond to a single topic resolved. Please clean up the patch from the unnecessary or over-complicated code to make reviewing easier. Before submiting the patch, update your local copy of the repository to ensure that the patch corresponds to the most up-to-date source code.

Read the comments of other team members and get involved into the discussion. Be prepared for critics and respond properly. The discussion is expected to highlight the weak points of the solution and thus may force you to recurse into the development stage again. This may be repeated a few times until the team is satisfied with the solution.

Once the agreement is reached, attach the final version of the patch to the appropriate tracker ticket. It will be included by the team members into the next Firebird release.

Alternatively, you may fork the repository at GitHub and contribute patches via pull requests.