Contributing

Developers:

To contribute with improvements and bug fix proceed as following:

1. Search for or start a discussion on Developers ML or Users ML
2. Someone will help you to understand if you need to open an issue or an improvement or (for bigger changes) you have to start a new proposal describing what you want to do, why, and how do you intend to proceed (this should be approved).
3. Provide a fix/improvement (with integration and junit test) making a pull request (on the same branch you are working on, usually the master one).
4. The patch now can be reviewed and or discussed
5. [if needed] you have to re-factor the patch on the same branch
6. Before the patch is merged you need to provide some documentation showing changes.

Contributions that are not in the form of a correct pull request and/or are missing Unit Tests will not be accepted!

The branch naming convention:

Use the branch, the issue number and a short description:

${branch}-${issue_number}-${short_description}

f.e.: master-61-LayerGroup-tests-failing

Commit messages may looks like:

61 fix LayerGroup test: introduce the fix ... 61 fix LayerGroup test: refactorize as requested

Please avoid using too much commits for a single fix.

Code formatting:

Please use formatted code as specified here

Java Doc:

We encourage you writing examples embedded into javadoc ref. here for standards.

Authors:

To keep a limited contributors list we ask you to follow following rules about the @author tag:

1. Consider to add @author only if you are creating the Class or if your patch will overwrite most of the code of a class.

2. Add @author tag ONLY at Class level (not for each method you implement)

If you want to know the list of all the contributors of the project, please use git log or reports.

Deploy

To perform a deploy please ref here

Release

To perform a release please ref here