Thank you for your interest in helping us to make OpenFastTrace (OFT) better!
This document aims at answering all the questions potential contributors to OFT might have before feeling ready to get started.
If you are looking for general information about what OpenFastTrace is, please make sure to check out the ReadMe that comes with the project.
If you are a programmer and want to help us improve the implementation, test cases or design of OFT please create a branch of the current main branch of OFT using git and make your changes on that branch.
Then please create a pull request and ask for a review by one of the core team members (e.g. redcatbear or kaklakariada).
The reviewers will either ask you to work in review findings or if there are none, merge your branch.
We are happy if you test OFT! While we do a great deal of testing ourselves, we want OFT to be as portable as possible. So it is especially helpful for us if you test on a platform that we don't have.
If you find a bug, please let us know by writing an issue ticket. There is a template for bug tickets that helps you provide all the information that we need to reproduce and tackle the bug you found.
If you are a programmer, a code contribution in form of an automatic unit test case would be most appreciated, since this will make reproduction of the issue easier and prevent future regressions.
Maybe you are good at explaining how to use OFT to end users? Help us improve the user guide!
We plan to make OFT multilingual. If you want to provide a translation, feel free to contact us. Messages in OFT and the user guide are prime candidates for translation.
Found a clever way to apply OFT in a new field of application? Share your story with the OFT community!
Last but not least if you have ideas for ways to improve or extend OFT, feel free to write a feature request.
We want OFT to have a professional and uniform coding style. Formatter rules for Eclipse are part of the project. If you use a different editor, please make sure to match the current code formatting.
We develop the code following the principles described in Robert C. Martin's book "Clean Code" as our guide line for designing and organizing the code.