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