How to Contribute¶
Contributions to Ratel are encouraged.
Please make your commits well-organized and atomic, using git rebase --interactive as needed.
Check that all tests pass using make prove or make junit.
If adding a new feature, please add or extend a test so that your new feature is tested.
In typical development, every commit should compile, be covered by the test suite, and pass all tests.
This improves the efficiency of reviewing and facilitates use of git bisect.
Open an issue or RFC (request for comments) merge request to discuss any significant changes before investing time. It is useful to create a WIP (work in progress) merge request for any long-running development so that others can be aware of your work and help to avoid creating merge conflicts.
Write commit messages for a reviewer of your merge request and for a future developer (maybe you) that bisects and finds that a bug was introduced in your commit. The assumptions that are clear in your mind while committing are likely not in the mind of whomever (possibly you) needs to understand it in the future.
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>.
Please use a real name and email for your author information (git config user.name and user.email).
If your author information or email becomes inconsistent (look at git shortlog -se), please edit .mailmap to obtain your preferred name and email address.
When contributors make a major contribution and support it, their names are included in the automatically generated user-manual documentation.
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. Rationale from Junio and Linus.
You can use make format to help conform to coding conventions of the project, but try to avoid mixing whitespace or formatting changes with content changes (see atomicity above).
By submitting a merge request, you are affirming the following.
Developer’s Certificate of Origin 1.1¶
By making a contribution to this project, I certify that:
(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
(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
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
(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.
LLM Generated Content¶
Ratel is a research software project, and we require citation of the origin of ideas in the same way that citations are expected for research papers. See the San Francisco Declaration on Research Assessment for discussion on treating other research outputs, such as datasets and software, as first class artifacts like research papers.
LLM/GenAI generated code can contain novel algorithms developed by other researchers and replicated without attribution. As such, we cannot accept merge requests containing code predominantly generated by LLM/GenAI.
LLMs may be used to aid the development of code for merge requests (MR); however, the individual submitting the MR must certify to its contents as described by Developer’s Certificate of Origin. The human creating the MR is ultimately responsible for the content in the MR. MRs must disclose and describe all LLM usage.