sphinx/source/CONTRIBUTING.md

4 <!---
5 Please use a pull request to the appropriate branch ('stable' for backward-compatible bug fixes for the last stable release, main' for new features and everything else).
6 -->
7 Please make your commits well-organized and [atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention), using `git rebase --interactive` as needed.
8 Check that tests (including "examples") pass using `make prove-all`.
9 If adding a new feature, please add or extend a test so that your new feature is tested.
12 This improves the efficiency of reviewing and facilitates use of [`git bisect`](https://git-scm.com/docs/git-bisect).
15 It is useful to create a WIP (work in progress) pull request for any long-running development so that others can be aware of your work and help to avoid creating merge conflicts.
17 Write commit messages for a reviewer of your pull request and for a future developer (maybe you) that bisects and finds that a bug was introduced in your commit.
20 Give credit where credit is due using tags such as `Reported-by: Helpful User <helpful@example.com>` or [`Co-authored-by: Snippet Mentor <code.by@comment.com>`](https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors#creating-co-authored-commits-on-the-command-line).
21 Please use a real name and email for your author information (`git config user.name` and `user.email`).
22 If your author information or email becomes inconsistent (look at `git shortlog -se`), please edit `.mailmap` to obtain your preferred name and email address.
24 When contributors make a major contribution and support it, their names are included in the automatically generated user-manual documentation.
26 Please avoid "merging from upstream" (like merging 'main' into your feature branch) unless there is a specific reason to do so, in which case you should explain why in the merge commit.
33 By submitting a pull request, you are affirming the following.
37 By making a contribution to this project, I certify that:
39 (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
41 (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
43 (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
45 (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
50 It is important that contributors receive appropriate recognition through informal and academically-recognized credit systems such as publications.
51 Status as a named author on the users manual and libCEED software publications will be granted for those who
58 Authors of publications about libCEED as a whole, including DOI-bearing archives, shall offer co-authorship to all individuals listed in the `AUTHORS` file.
59 Authors of publications claiming specific libCEED contributions shall evaluate those listed in `AUTHORS` and offer co-authorship to those who made significant intellectual contributions to the work.
61 Note that there is no co-authorship expectation for those publishing about use of libCEED (versus creation of new features in libCEED), but see the [citing section](https://libceed.org/en/latest/gettingstarted/#how-to-cite) and use your judgment regarding significance of support/advice you may have received in developing your use case and interpreting results.