xref: /netbsd-src/external/apache2/llvm/dist/libcxx/utils/google-benchmark/CONTRIBUTING.md (revision 4d6fc14bc9b0c5bf3e30be318c143ee82cadd108)
1*4d6fc14bSjoerg# How to contribute #
2*4d6fc14bSjoerg
3*4d6fc14bSjoergWe'd love to accept your patches and contributions to this project.  There are
4*4d6fc14bSjoerga just a few small guidelines you need to follow.
5*4d6fc14bSjoerg
6*4d6fc14bSjoerg
7*4d6fc14bSjoerg## Contributor License Agreement ##
8*4d6fc14bSjoerg
9*4d6fc14bSjoergContributions to any Google project must be accompanied by a Contributor
10*4d6fc14bSjoergLicense Agreement.  This is not a copyright **assignment**, it simply gives
11*4d6fc14bSjoergGoogle permission to use and redistribute your contributions as part of the
12*4d6fc14bSjoergproject.
13*4d6fc14bSjoerg
14*4d6fc14bSjoerg  * If you are an individual writing original source code and you're sure you
15*4d6fc14bSjoerg    own the intellectual property, then you'll need to sign an [individual
16*4d6fc14bSjoerg    CLA][].
17*4d6fc14bSjoerg
18*4d6fc14bSjoerg  * If you work for a company that wants to allow you to contribute your work,
19*4d6fc14bSjoerg    then you'll need to sign a [corporate CLA][].
20*4d6fc14bSjoerg
21*4d6fc14bSjoergYou generally only need to submit a CLA once, so if you've already submitted
22*4d6fc14bSjoergone (even if it was for a different project), you probably don't need to do it
23*4d6fc14bSjoergagain.
24*4d6fc14bSjoerg
25*4d6fc14bSjoerg[individual CLA]: https://developers.google.com/open-source/cla/individual
26*4d6fc14bSjoerg[corporate CLA]: https://developers.google.com/open-source/cla/corporate
27*4d6fc14bSjoerg
28*4d6fc14bSjoergOnce your CLA is submitted (or if you already submitted one for
29*4d6fc14bSjoerganother Google project), make a commit adding yourself to the
30*4d6fc14bSjoerg[AUTHORS][] and [CONTRIBUTORS][] files. This commit can be part
31*4d6fc14bSjoergof your first [pull request][].
32*4d6fc14bSjoerg
33*4d6fc14bSjoerg[AUTHORS]: AUTHORS
34*4d6fc14bSjoerg[CONTRIBUTORS]: CONTRIBUTORS
35*4d6fc14bSjoerg
36*4d6fc14bSjoerg
37*4d6fc14bSjoerg## Submitting a patch ##
38*4d6fc14bSjoerg
39*4d6fc14bSjoerg  1. It's generally best to start by opening a new issue describing the bug or
40*4d6fc14bSjoerg     feature you're intending to fix.  Even if you think it's relatively minor,
41*4d6fc14bSjoerg     it's helpful to know what people are working on.  Mention in the initial
42*4d6fc14bSjoerg     issue that you are planning to work on that bug or feature so that it can
43*4d6fc14bSjoerg     be assigned to you.
44*4d6fc14bSjoerg
45*4d6fc14bSjoerg  1. Follow the normal process of [forking][] the project, and setup a new
46*4d6fc14bSjoerg     branch to work in.  It's important that each group of changes be done in
47*4d6fc14bSjoerg     separate branches in order to ensure that a pull request only includes the
48*4d6fc14bSjoerg     commits related to that bug or feature.
49*4d6fc14bSjoerg
50*4d6fc14bSjoerg  1. Do your best to have [well-formed commit messages][] for each change.
51*4d6fc14bSjoerg     This provides consistency throughout the project, and ensures that commit
52*4d6fc14bSjoerg     messages are able to be formatted properly by various git tools.
53*4d6fc14bSjoerg
54*4d6fc14bSjoerg  1. Finally, push the commits to your fork and submit a [pull request][].
55*4d6fc14bSjoerg
56*4d6fc14bSjoerg[forking]: https://help.github.com/articles/fork-a-repo
57*4d6fc14bSjoerg[well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
58*4d6fc14bSjoerg[pull request]: https://help.github.com/articles/creating-a-pull-request
59