We are happy to have contributions whether for small bug fixes or major new pieces of functionality. There's always something in the issue tracker to take on.
The best way to help out would be to look at the issue tracker and check what needs done. Code contributions are welcome but they are not the only way to make a contribution to Apollo. Quality assurance is a very important part of this project, as is documentation. Any help offered with those is greatly appreciated.
Apollo uses GitHub pull requests for reviewing and accepting changes, and so to contribute a change to Apollo you should first fork the upstream repository to your own GitHub account.
Once you have a copy of your own forked repository locally you should
add a new remote for upstream, so you can rebase any changes
you make and keep up to date with upstream.
git remote add upstream https://github.com/apollo-rsps/apollo.git
- If the change is non-trivial please include some unit tests that cover the new functionality.
- If you are introducing a completely new feature or API it is a good idea to start a discussion on IRC and get consensus on the basic design first.
- Make sure you have observed the recommendations in the style guide below.
- It is our job to follow up on patches in a timely fashion. Nag us if we aren't doing our job (sometimes we drop things).
The Apollo project uses a coding style based on the Google style guide. Please use that as a reference for any code changes. Checkstyle rules will be coming soon.
Additionally to the recommendations above, see the below guidelines for code changes:
Basic Stuff
- Avoid cryptic abbreviations. Single letter variable names are fine in very short methods with few variables, otherwise make them informative.
- Clear code is preferable to comments. When possible make your naming so good you don't need comments. When that isn't possible comments should be thought of as mandatory, write them to be read.
- Logging, configuration, and public APIs are our "UI". Make them pretty, consistent, and usable.
- Don't be sloppy. Don't check in commented out code: we use version control, it is still there in the history. Don't leave TODOs in the code or FIXMEs if you can help it. Don't leave println statements in the code. Hopefully this is all obvious.
- We want people to use our stuff, which means we need clear, correct documentation. User documentation should be considered a part of any user-facing the feature, just like unit tests or performance results.
- Don't duplicate code (duh).
If you want to chat or need any assistance with a problem in Apollo feel free to contact us on the IRC channel at #apollorsps on irc.freenode.net.
most of the above is loosely borrowed from the great Apache kafka project