diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 47e7939..efb8ef0 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -6,7 +6,7 @@ List any dependencies that are required for this change. Fixes #(issue) -## Checklist: +## Checklist + + +# AI Usage Guidelines + +We acknowledge that AI tools (Large Language Models, code completion engines like GitHub Copilot, etc.) have become helpful assistants for many developers. +We allow the use of these tools to assist with contributions, provided that their use is transparent, responsible, and that a **human remains in the loop** at all times. + +This guide outlines our policy on AI-assisted contributions to ensure code quality, maintainability, and legal compliance. + +## Core Principles + +### 1. You are Responsible + +**You are responsible for every line of code you submit.** + +Regardless of whether code was written by you or generated by an AI tool, you are the author and are fully accountable for the contribution. You must: + +- Fully understand the code you are submitting. +- Be able to explain the reasoning behind the code and how it interacts with the rest of the codebase. +- Verify that the code is correct, efficient, and follows our coding standards. + +**Do not blindly copy-paste AI-generated code.** If you cannot explain it, do not submit it. + +### 2. Human in the Loop + +> **Autonomous contributions from AI agents are not allowed.** + +When using AI tools, you must be the driver. +The AI is the assistant. + +- **Review:** You must read and review all AI-generated code or text before submitting it. +- **Edit:** AI-generated code often requires significant editing to meet project standards and correctness. +- **Verify:** Ensure the code actually solves the problem and doesn't introduce subtle bugs or security vulnerabilities. + +### 3. Communication + +**Do not use AI tools to generate issue descriptions, pull request comments, or code reviews.** + +We value your personal input and communication. +LLMs are notoriously unreliable and can produce "smart-sounding" but incorrect or irrelevant claims ("hallucinations"). +Phrase your communications in your own words. +It is more important that we can follow your reasoning than that the text sounds "perfect". + +### 4. Transparency and Disclosure + +Transparency helps the community understand the role of these tools and develop best practices. + +**We encourage you to disclose any AI assistance.** +This helps us understand how these tools are being used and identify potential issues. +You can disclose this information in the following ways: + +- **Commit Messages**: Add a trailer to your commit message in the form `Assisted-by: [Model Name] via [Tool Name]` (example: `Assisted-by: Claude Sonnet 4.6 via GitHub Copilot`) +- **PR Description**: Mention the tool (name and version) and how it was used in the PR description. + +### 5. Licensing and Copyright + +You are responsible for ensuring that your contribution does not violate any third-party licenses or copyrights. + +- **Originality**: Your submission must be your own original work of authorship. +- **Training Data**: Be aware that some AI tools may generate code that is substantially similar to their training data. You must ensure that you have the right to contribute the generated code under [our license](https://github.com/munich-quantum-toolkit/workflows/blob/main/LICENSE.md). + +## Extractive Contributions + +Processing pull requests and comments for MQT Reusable Workflows requires significant maintainer time and energy. +Sending unreviewed AI output to open-source projects shifts the burden of verifying correctness from the contributor to the maintainer. +We classify such contributions as "extractive" because they consume more community resources than they provide in value. + +Our **golden rule** is that a contribution should be valuable enough to justify the review effort. +Nadia Eghbal captures this concept in her book _[Working in Public](https://press.stripe.com/working-in-public)_: + +> "When attention is being appropriated, producers need to weigh the costs and benefits of the transaction. To assess whether the appropriation of attention is net-positive, it's useful to distinguish between _extractive_ and _non-extractive_ contributions. Extractive contributions are those where the marginal cost of reviewing and merging that contribution is greater than the marginal benefit to the project's producers. In the case of a code contribution, it might be a pull request that's too complex or unwieldy to review, given the potential upside." — Nadia Eghbal + +Before AI tools became widespread, open-source project maintainers would often review all changes sent to the project simply because submitting a pull request was a sign of interest from a potential long-term contributor. +However, AI tools now allow the rapid generation of large volumes of code, which can easily overwhelm maintainers if submitted without careful review. +Our policy exists to ensure that maintainer time is spent on high-quality interactions rather than debugging AI-generated code. + +### Sustainable Open Source + +The Munich Quantum Toolkit (MQT) is committed to remaining free, open-source, and permissively licensed. +We want to build a welcoming community where aspiring quantum software engineers can learn and grow. +Reviewing contributions is a key part of this mentorship. + +However, to keep the project sustainable, we must prioritize non-extractive contributions. +By thoroughly reviewing and understanding your AI-assisted code before submission, you ensure that your contribution is a net positive for the project. +This helps us maintain a healthy ecosystem where both the software and its contributors can thrive. + +## Prohibited Uses + +- **"Good First Issues"**: Do not use AI tools to solve issues labeled as "good first issue". These are intended as learning opportunities for new contributors. Automating them defeats the purpose. +- **Spam**: Do not use AI to generate low-quality or repetitive comments/reviews ("AI Slop"). +- **Unreviewed Code**: Submitting code that you, as a human, have not reviewed and tested yourself. + +## Summary + +We want to foster a welcoming community where developers can learn and grow. AI tools can be great for productivity, but they should not replace critical thinking or the learning process. +If a maintainer judges that a contribution relies too heavily on unverified AI generation or lacks sufficient human understanding ("extractive contribution"), we may request that you revise it or close the PR. + +--- + +Parts of this guide were inspired by or adapted from the contribution guidelines of + +- [Astral], +- [Qiskit], +- [LLVM], including the sources therein, such as [Fedora Council Policy Proposal: Policy on AI-Assisted Contributions (fetched 2026-03-12)][fedora], which is licensed under the [Creative Commons Attribution 4.0 International License][cca]. + +with the help of Gemini 3 Pro (Preview). The links above serve as attribution. + +[Astral]: https://github.com/astral-sh/uv/blob/c89a78ec085077f6344b0439ddf07fdad7336310/CONTRIBUTING.md +[Qiskit]: https://github.com/Qiskit/qiskit/blob/cd8701690723d3d9602fac63fe0bd7ea618799be/CONTRIBUTING.md#use-of-ai-tools +[LLVM]: https://github.com/llvm/llvm-project/blob/9b6391f9c439c9926e8587b7b940e9a1e98a7819/llvm/docs/AIToolPolicy.md +[fedora]: https://communityblog.fedoraproject.org/council-policy-proposal-policy-on-ai-assisted-contributions/ +[cca]: https://creativecommons.org/licenses/by/4.0/