First off, thank you for considering contributing to jxvc. Like any open source project, our project can only get better with contributions from other developers.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
jxvc are keen to accept any form of contributions. However, take a moment to classify your contribution before making it.
- Bugs are software faults, create an issue in the github issue tracker and label it as a bug. Please clearly identify which subproject the bug is likely to be in. If you have the inclination and time, write a failing test case which demonstrates the bug and submit it as a patch.
- Security bugs should not be logged in the (public) issue tracker. Please communicate directly with the developers.
- Standards compliance issues. jxvc strives to be compliant with various ISO standards as documented elsewhere. If you feel that jxvc is non-compliant, log it as a bug (see above).
- Feature requests can be logged in the issue tracker as above. Simply tag the issue as a feature.
- Support requests should not be documented in the issue tracker, at least not directly. We don't yet have a mailing list, but should you need support - create an issue along the lines of "You need a mailing list to handle support". We'll contact you about your issue and also look to create a mailing list.
Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.
The general process expected in the jxvc project is as follows:
- Make sure there is an issue in the issue tracker - if not, create one first with basic documentation of the bug/feature justifying the fix.
- Discuss the issue via the comment section of the issue. We know your time is valuable and we want to make sure your changes go in the right place. For features its an especially good idea to rough out an idea of what you plan to do and get one of the developers to review it before starting work. At a minimum, make a comment that you are about to start working on the issue.
- fork the jxvc project and create a branch of your fork to work on.
- Write a failing test case! We generally don't accept code submissions without test cases. It's not a bad idea to commit your failing test case in a separate commit so we can appreciate the fault.
- If you discover you need to do a largish refactor, before fixing your issue, create a separate issue "Refactor for issue xxx" and do the refactor first, in a different branch and pull request.
- Commit your change with a full commit message, including
- The issue number of the issue fixed (only one issue per commit / pull request please)
- What the issue is and what the outcome of your fix is. Don't be afraid to be detailed. It's not a bad idea to copy the original description from the bug / feature report as a starting point.
- Create a pull request to notify us of the fix.
- Sit back and relax!