1# libCEED: How to Contribute 2 3Contributions to libCEED are encouraged. 4<!--- 5Please use a pull request to the appropriate branch ('maint' for 6backward-compatible bug fixes for the last stable release, 'master' for 7new features and everything else). 8--> 9Please make your commits well-organized and 10[atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention), 11using `git rebase --interactive` as needed. Check that tests 12(including "examples") pass using `make prove-all`. If adding a new 13feature, please add or extend a test so that your new feature is 14tested. 15 16In typical development, every commit should compile, be covered by the 17test suite, and pass all tests. This improves the efficiency of 18reviewing and facilitates use of 19[`git bisect`](https://git-scm.com/docs/git-bisect). 20 21Open an issue or RFC (request for comments) pull request to discuss 22any significant changes before investing time. It is useful to create 23a WIP (work in progress) pull request for any long-running development 24so that others can be aware of your work and help to avoid creating 25merge conflicts. 26 27Write commit messages for a reviewer of your pull request and for a 28future developer (maybe you) that bisects and finds that a bug was 29introduced in your commit. The assumptions that are clear in your 30mind while committing are likely not in the mind of whomever (possibly 31you) needs to understand it in the future. 32 33Give credit where credit is due using tags such as `Reported-by: 34Helpful User <helpful@example.com>`. Please use a real name and email 35for your author information (`git config user.name` and `user.email`). 36 37When contributors make a major contribution and support it, their names 38are included in the automatically generated user-manual documentation. 39 40Please avoid "merging from upstream" (like merging 'master' into your 41feature branch) unless there is a specific reason to do so, in which 42case you should explain why in the merge commit. 43[Rationale](https://lwn.net/Articles/328436/) from 44[Junio](https://gitster.livejournal.com/42247.html) and 45[Linus](http://yarchive.net/comp/linux/git_merges_from_upstream.html). 46 47You can use `make style` to help conform to coding conventions of the 48project, but try to avoid mixing whitespace or formatting changes with 49content changes (see atomicity above). 50 51By submitting a pull request, you are affirming the following. 52 53## [Developer's Certificate of Origin 1.1](https://developercertificate.org/) 54 55By making a contribution to this project, I certify that: 56 57(a) The contribution was created in whole or in part by me and I 58 have the right to submit it under the open source license 59 indicated in the file; or 60 61(b) The contribution is based upon previous work that, to the best 62 of my knowledge, is covered under an appropriate open source 63 license and I have the right under that license to submit that 64 work with modifications, whether created in whole or in part 65 by me, under the same open source license (unless I am 66 permitted to submit under a different license), as indicated 67 in the file; or 68 69(c) The contribution was provided directly to me by some other 70 person who certified (a), (b) or (c) and I have not modified 71 it. 72 73(d) I understand and agree that this project and the contribution 74 are public and that a record of the contribution (including all 75 personal information I submit with it, including my sign-off) is 76 maintained indefinitely and may be redistributed consistent with 77 this project or the open source license(s) involved. 78 79 80