How to contribute

Welcome and thank you for your interest in contributing to Apache Corinthia! This guide will take you through the process of making contributions to the Apache Corinthia code base.

Contributor license agreement

Apache Corinthia is licensed under the Apache License, Version 2.0. All contributions will be under this license, Please read and understand this license before contributing.
For all but the most trivial patches, you are required to file a Contributor License Agreement with the Apache Software Foundation.
Please read the guide to CLAs to find out how to file a CLA with the Foundation.

Before you start - join the community

If it is your first contribution or it is a particularly big or complex contribution,things typically go much more smoothly when they start off with a conversation. Join our development mailing list.

Create an issue in Jira

Your first step is to create or find an issue in Corinthi Jira for your feature request or fix. For small changes this is not necessary, but it is good to see if your change fixes an existing issue anyway.

Contributing using GitHub

This is our preferred way for contributing code for non-committers. Our GitHub repo is located at https://github.com/apache/incubator-corinthia. Your commit messages must properly describes the changes that have been made and their purpose (here are some guidelines).
- If your contributions fix a Jira issue***, then ensure that you reference the issue (like CORINTHIA-9876***) in the commit message.
- Create a pull request (PR) in GitHub for the change. The comment must contain a link to the JirA*** issue (if it has one).
Some good references for working with GitHub can be found on our GIT FAQ page. We ask that you keep your change rebased to master as much as possible, and we will ask you to rebase again if master has moved before accepting your patch.

Reviews

The Apache Corinthia community will review your pull request before it is merged. This process can take a while, so please be patient. If we are slow to respond, please feel free to post a reminder to the mailing list - see the home page to see how to contact us.
During the review process you may be asked to make some changes to your submission. While working through feedback, it can be beneficial to create new commits so the incremental change is obvious. This can also lead to a complex set of commits, and having an atomic change per commit is preferred.
Use your best judgement and work with your reviewer as to when you should revise a commit or create a new one.
A pull request is considered ready to be merged once it gets at lease one +1 from a committer. Once all the changes have been completed and the pull request is accepted, you may be asked to rebase it against the latest code. You may also wish to squash some commits together and make other history revisions, to leave the commit history clean and easily understood.

Contributing without using GitHub

If you prefer to not use GitHub, then that is fine - we are also happy to accept patches attached to a Jira issue.
Our canonical repository is located at

When producing patches, please use git format-patch or a similar mechanism - this will ensure that you are properly attributed as the author of the patch when a committer merges it.