From 5891d4b64befe9635c1c08333f9561a82877d211 Mon Sep 17 00:00:00 2001 From: Daniel Lemire Date: Thu, 26 Feb 2026 15:09:40 -0500 Subject: [PATCH] adding AI policy --- .github/ISSUE_TEMPLATE/bug_report.md | 3 ++ .github/pull_request_template.md | 2 +- AI_USAGE_POLICY.md | 56 ++++++++++++++++++++++++++++ CONTRIBUTING.md | 7 ++++ 4 files changed, 67 insertions(+), 1 deletion(-) create mode 100644 AI_USAGE_POLICY.md diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index f509f12ba..0815e1dd8 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -29,6 +29,9 @@ We accept the identification of an issue by a sanitizer or some checker tool (e. We recommend that you run your tests using different optimization levels. In particular, we recommend your run tests with the simdjson library and you code compiled in debug mode. The simdjson then sets the SIMDJSON_DEVELOPMENT_CHECKS macro to 1, and this triggers additional checks on your code and on the internals of the library. If possible, we recommend that you run tests with sanitizers (e.g., see [No more leaks with sanitize flags in gcc and clang](https://lemire.me/blog/2016/04/20/no-more-leaks-with-sanitize-flags-in-gcc-and-clang/)). You can compile the library with sanitizers for debugging purposes (e.g., set SIMDJSON_SANITIZE to ON using CMake), but you should also turn on sanitizers on your own code. You may also use tools like valgrind or the commercial equivalent. +Mixing debug and release simdjson code is unsafe: you either build all your code using simdjson in +release mode or all of it in debug mode. + Before reporting a bug, please ensure that you have read our documentation. **To Reproduce** diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 9db292e39..0b0769137 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -20,7 +20,7 @@ How to verify / test Please read before contributing: - CONTRIBUTING: https://github.com/simdjson/simdjson/blob/master/CONTRIBUTING.md - HACKING: https://github.com/simdjson/simdjson/blob/master/HACKING.md - +- AI Usage Policy: https://github.com/simdjson/simdjson/blob/master/AI_USAGE_POLICY.md If you can, we recommend running our tests with the sanitizers turned on. diff --git a/AI_USAGE_POLICY.md b/AI_USAGE_POLICY.md new file mode 100644 index 000000000..a13ff82af --- /dev/null +++ b/AI_USAGE_POLICY.md @@ -0,0 +1,56 @@ +# AI Usage Policy + +Contributors can use whatever tools they would like to +craft their contributions, but there must be a **human in the loop**. +**Contributors must read and review all LLM-generated code or text before they +ask other project members to review it.** The contributor is always the author +and is fully accountable for their contributions. Contributors should be +sufficiently confident that the contribution is high enough quality that asking +for a review is a good use of scarce maintainer time, and they should be **able +to answer questions about their work** during review. + +We expect that new contributors will be less confident in their contributions, +and our guidance to them is to **start with small contributions** that they can +fully understand to build confidence. We aspire to be a welcoming community +that helps new contributors grow their expertise, but learning involves taking +small steps, getting feedback, and iterating. Passing maintainer feedback to an +LLM doesn't help anyone grow, and does not sustain our community. + +This policy includes, but is not limited to, the following kinds of +contributions: + +- Code, usually in the form of a pull request +- Issues or security vulnerabilities +- Comments and feedback on pull requests + +## Extractive Contributions + +The reason for our "human-in-the-loop" contribution policy is that processing +patches, PRs, RFCs, and comments is not free -- it takes a lot of +maintainer time and energy to review those contributions! Sending the +unreviewed output of an LLM to open source project maintainers *extracts* work +from them in the form of design and code review, so we call this kind of +contribution an "extractive contribution". + +## Transparency + +For contributions involving significant AI assistance, we encourage you to disclose +its use and explain your process. If a submission appears to rely heavily on AI +without disclosure, we may doubt that the **human-in-the-loop** requirement has +been met. Please show awareness of your use of AI. + +## Copyright + +Artificial intelligence systems raise many questions around copyright that have +yet to be answered. Our policy on AI tools is similar to our copyright policy: +Contributors are responsible for ensuring that they have the right to +contribute code under the terms of our license, typically meaning that either +they, their employer, or their collaborators hold the copyright. Using AI tools +to regenerate copyrighted material does not remove the copyright, and +contributors are responsible for ensuring that such material does not appear in +their contributions. Contributions found to violate this policy will be removed +just like any other offending contribution. + +## Reference + +- [LLVM AI Tool Use Policy](https://discourse.llvm.org/t/rfc-llvm-ai-tool-policy-human-in-the-loop/89159) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a9cf186e4..14b2ccbfc 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -101,3 +101,10 @@ Getting Started Hacking An overview of simdjson's directory structure, with pointers to architecture and design considerations and other helpful notes, can be found at [HACKING.md](HACKING.md). + + + +AI Usage Policy +--------------- + +Please also review our [AI Usage Policy](AI_USAGE_POLICY.md).