1# How to contribute 2 3Adding great features and ensuring the widest possible platform compatibility requires community participation. Anyone wishing to contribute should review these guidelines before submitting pull requests. 4 5## Celero Core vs Example Experiments 6 7New functionality would reside inside the core project for Celero. Here it is most important that guidelines are followed to include code formatting, ISO C++ compliance, etc. The requirements on example experiments are less strict to allow individuals to share their projects the way they wrote them, though adherence to coding standards would be greatly appreciated. 8 9## Getting Started 10 11* Make sure you have a [GitHub account](https://github.com/signup/free) 12* Submit a ticket for your issue, assuming one does not already exist. 13* Clearly describe the issue including steps to reproduce when it is a bug. 14* Make sure you fill in the earliest version that you know has the issue. 15* Fork the repository on GitHub 16 17## Making Changes 18 19Change should generally follow the [Git Flow](http://nvie.com/posts/a-successful-git-branching-model/) branching model. 20 21* Create a topic branch from where you want to base your work. [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/). 22* All pull requests should be made against the "develop" branch. 23* Make commits of logical units. 24* Check for unnecessary whitespace with `git diff --check` before committing. 25* Make sure your commit messages are in the proper format. 26* Use clang-format to format your files after you make changes. Use Celero's custom .clang-format file for its configuration. 27 28For details, see ["Writing good commit messages.""](https://github.com/erlang/otp/wiki/Writing-good-commit-messages). 29 30* Make sure you have added the necessary Google tests for your changes. 31* Run _all_ the tests to assure nothing else was accidentally broken. 32 33## Making Trivial Changes 34 35### Documentation 36 37For changes to how a user would run Celero from a command line or how a user might build Celero benchmarks, please provide the appropriate updates to README.md documenting the changes. In-line code documentaiton following the Doxygen markup language should also be accomplished within the code. 38 39## Submitting Changes 40 41* Push your changes to a topic branch in your fork of the repository. 42* Submit a pull request to the "develop" branch of the Celero repository. 43* Update your Jira ticket to mark that you have submitted code and are ready for it to be reviewed (Status: Ready for Merge). 44* Include a link to the pull request in the ticket. 45* After feedback has been given we expect responses within two weeks. After two weeks we may close the pull request if it isn't showing any activity. 46 47## Additional Resources 48 49* ["Writing good commit messages.""](https://github.com/erlang/otp/wiki/Writing-good-commit-messages) 50* [General GitHub documentation](http://help.github.com/) 51* [Git Flow](http://nvie.com/posts/a-successful-git-branching-model/) 52* [GitHub pull request documentation](http://help.github.com/send-pull-requests/) 53* [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/) 54