We are always very happy to have contributions, whether for trivial cleanups or big new features,and we hope this document will help to make the process as smooth as possible.
Nor is code the only way to contribute to the project. We strongly value documentation and gladly accept improvements to the documentation.
To avoid duplication of effort, let us know what you’re planning to contribute before you write the code. It will also help us to plan some time to review your changes.
We recommend creating an issue on Github detailing the change you would like to make. It can be a bug fix, a documentation update or a new feature request.
If you are adding new major feature, we suggest that you add a design document and solicit comments before submitting any code. You can link your design doc to your Github issue.
If you’re only fixing a bug, or updating the documentation, you can submit a pull request right away.
Please ensure your code is adequately documented. Add a summary of your contribution to the top of the CHANGELOG file.
Depends on the nature of your change, we also recommend to update our user guide. Please follow the instructions: https://github.com/linkedin/rest.li/tree/gh-pages
Follow coding conventions, include documentation and write tests. Look to the surrounding code for example.
Contributions should be submitted as GitHub pull requests.
The Rest.Li team at LinkedIn is monitoring for pull requests. We will review, and update your changes with an explanation. Rest.li is under active development and massively used at LinkedIn. Your changes might require additional efforts on our side to fix our internal uses, which could cause some delay. We’ll do our best to provide updates and feedback throughout the process.