You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/pull_request_template.md
+6-1Lines changed: 6 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,12 @@ Please include a summary of the change and, if applicable, which issue is fixed.
4
4
Please also include relevant motivation and context.
5
5
List any dependencies that are required for this change.
6
6
7
-
Fixes #(issue) <!--- Replace `(issue)` with the issue number fixed by this pull request. If this PR does not fix an issue, please remove this line. -->
7
+
<!---
8
+
Replace `(issue)` with the issue number fixed by this pull request.
9
+
If this PR does not fix an issue, please remove the line.
Copy file name to clipboardExpand all lines: AGENTS.md
+28-10Lines changed: 28 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,25 +42,43 @@
42
42
### General
43
43
44
44
- MUST run `uvx nox -s lint` after every batch of changes.
45
-
This runs the full `prek` hook set from `.pre-commit-config.yaml` (including `ruff`, `typos`, `ty`, formatting, and metadata checks).
45
+
This runs the full `prek` hook set from `.pre-commit-config.yaml`
46
+
(including `ruff`, `typos`, `ty`, formatting, and metadata checks).
46
47
All hooks must pass before submitting.
47
-
- MUST add or update tests for every code change, even if not explicitly requested.
48
+
- MUST add or update tests for every code change,
49
+
even if not explicitly requested.
48
50
- MUST follow existing code style by checking neighboring files for patterns.
49
-
- MUST update `CHANGELOG.md` and `UPGRADING.md` when changes are user-facing, breaking, or otherwise noteworthy.
50
-
- MUST include a commit footer attribution in the form `Assisted-by: [Model Name] via [Tool Name]` (example: `Assisted-by: Claude Sonnet 4.6 via GitHub Copilot`) if AI tools are used to prepare a commit.
51
-
- NEVER modify files that start with "This file has been generated from an external template. Please do not modify it directly."
52
-
These files are managed by [the MQT templates action](https://github.com/munich-quantum-toolkit/templates) and changes will be overwritten.
51
+
- MUST update `CHANGELOG.md` and `UPGRADING.md` when changes are user-facing,
52
+
breaking, or otherwise noteworthy.
53
+
- MUST include a commit footer attribution in the form
54
+
`Assisted-by: [Model Name] via [Tool Name]` (example:
55
+
`Assisted-by: Claude Sonnet 4.6 via GitHub Copilot`) if AI tools are used to
56
+
prepare a commit.
57
+
- NEVER modify files that start with "This file has been generated from an
- PREFER running targeted tests over the full test suite during development.
54
64
55
65
### Python
56
66
57
67
- MUST use Google-style docstrings
58
-
- PREFER running a single Python version over the full test suite during development.
59
-
- PREFER fixing reported warnings over suppressing them (e.g., with `# noqa` comments for ruff); only add ignore rules when necessary and document why.
60
-
- PREFER fixing typing issues reported by `ty` before adding suppression comments (`# ty: ignore[code]`); suppressions are sometimes necessary for incompletely typed libraries (e.g., Qiskit).
68
+
- PREFER running a single Python version over the full test suite during
69
+
development.
70
+
- PREFER fixing reported warnings over suppressing them
71
+
(e.g., with `# noqa` comments for ruff);
72
+
only add ignore rules when necessary and document why.
73
+
- PREFER fixing typing issues reported by `ty`
74
+
before adding suppression comments
75
+
(`# ty: ignore[code]`);
76
+
suppressions are sometimes necessary for incompletely typed libraries
77
+
(e.g., Qiskit).
61
78
62
79
## Self-Review Checklist
63
80
64
81
- Did `uvx nox -s lint` pass without errors?
65
82
- Are all changes covered by at least one automated test?
66
-
- Are `CHANGELOG.md` and `UPGRADING.md` updated when changes are user-facing, breaking, or otherwise noteworthy?
83
+
- Are `CHANGELOG.md` and `UPGRADING.md` updated when changes are user-facing,
We acknowledge that AI tools (Large Language Models, code completion engines like GitHub Copilot, etc.) have become helpful assistants for many developers.
7
-
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.
6
+
We acknowledge that AI tools
7
+
(Large Language Models, code completion engines like GitHub Copilot, etc.)
8
+
have become helpful assistants for many developers.
9
+
We allow the use of these tools to assist with contributions,
10
+
provided that their use is transparent, responsible,
11
+
and that a **human remains in the loop** at all times.
8
12
9
-
This guide outlines our policy on AI-assisted contributions to ensure code quality, maintainability, and legal compliance.
13
+
This guide outlines our policy on AI-assisted contributions to ensure code
14
+
quality, maintainability, and legal compliance.
10
15
11
16
## Core Principles
12
17
13
18
### 1. You are Responsible
14
19
15
20
**You are responsible for every line of code you submit.**
16
21
17
-
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:
22
+
Regardless of whether code was written by you or generated by an AI tool,
23
+
you are the author and are fully accountable for the contribution.
24
+
You must:
18
25
19
26
- Fully understand the code you are submitting.
20
-
- Be able to explain the reasoning behind the code and how it interacts with the rest of the codebase.
27
+
- Be able to explain the reasoning behind the code
28
+
and how it interacts with the rest of the codebase.
21
29
- Verify that the code is correct, efficient, and follows our coding standards.
22
30
23
-
**Do not blindly copy-paste AI-generated code.** If you cannot explain it, do not submit it.
31
+
**Do not blindly copy-paste AI-generated code.**
32
+
If you cannot explain it, do not submit it.
24
33
25
34
### 2. Human in the Loop
26
35
@@ -29,82 +38,139 @@ Regardless of whether code was written by you or generated by an AI tool, you ar
29
38
When using AI tools, you must be the driver.
30
39
The AI is the assistant.
31
40
32
-
-**Review:** You must read and review all AI-generated code or text before submitting it.
33
-
-**Edit:** AI-generated code often requires significant editing to meet project standards and correctness.
34
-
-**Verify:** Ensure the code actually solves the problem and doesn't introduce subtle bugs or security vulnerabilities.
41
+
-**Review:** You must read and review all AI-generated code or text
42
+
before submitting it.
43
+
-**Edit:** AI-generated code often requires significant editing to meet project
44
+
standards and correctness.
45
+
-**Verify:** Ensure the code actually solves the problem
46
+
and doesn't introduce subtle bugs or security vulnerabilities.
35
47
36
48
### 3. Communication
37
49
38
-
**Do not use AI tools to generate issue descriptions, pull request comments, or code reviews.**
50
+
**Do not use AI tools to generate issue descriptions, pull request comments, or
51
+
code reviews.**
39
52
40
53
We value your personal input and communication.
41
-
LLMs are notoriously unreliable and can produce "smart-sounding" but incorrect or irrelevant claims ("hallucinations").
54
+
LLMs are notoriously unreliable and can produce "smart-sounding" but incorrect
55
+
or irrelevant claims ("hallucinations").
42
56
Phrase your communications in your own words.
43
-
It is more important that we can follow your reasoning than that the text sounds "perfect".
57
+
It is more important that we can follow your reasoning than
58
+
that the text sounds "perfect".
44
59
45
60
### 4. Transparency and Disclosure
46
61
47
-
Transparency helps the community understand the role of these tools and develop best practices.
62
+
Transparency helps the community understand the role of these tools
63
+
and develop best practices.
48
64
49
65
**We encourage you to disclose any AI assistance.**
50
-
This helps us understand how these tools are being used and identify potential issues.
66
+
This helps us understand how these tools are being used
67
+
and identify potential issues.
51
68
You can disclose this information in the following ways:
52
69
53
-
-**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`)
54
-
-**PR Description**: Mention the tool (name and version) and how it was used in the PR description.
70
+
-**Commit Messages**: Add a trailer to your commit message in the form
71
+
`Assisted-by: [Model Name] via [Tool Name]` (example:
72
+
`Assisted-by: Claude Sonnet 4.6 via GitHub Copilot`)
73
+
-**PR Description**: Mention the tool
74
+
(name and version) and how it was used in the PR description.
55
75
56
76
### 5. Licensing and Copyright
57
77
58
-
You are responsible for ensuring that your contribution does not violate any third-party licenses or copyrights.
78
+
You are responsible for ensuring
79
+
that your contribution does not violate any third-party licenses or copyrights.
59
80
60
-
-**Originality**: Your submission must be your own original work of authorship.
61
-
-**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/predictor/blob/main/LICENSE.md).
81
+
-**Originality**:
82
+
Your submission must be your own original work of authorship.
83
+
-**Training Data**: Be aware that some AI tools may generate code
84
+
that is substantially similar to their training data.
85
+
You must ensure that you have the right to contribute the generated code under
Processing pull requests and comments for MQT Predictor requires significant maintainer time and energy.
66
-
Sending unreviewed AI output to open-source projects shifts the burden of verifying correctness from the contributor to the maintainer.
67
-
We classify such contributions as "extractive" because they consume more community resources than they provide in value.
68
-
69
-
Our **golden rule** is that a contribution should be valuable enough to justify the review effort.
70
-
Nadia Eghbal captures this concept in her book _[Working in Public](https://press.stripe.com/working-in-public)_:
71
-
72
-
> "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
73
-
74
-
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.
75
-
However, AI tools now allow the rapid generation of large volumes of code, which can easily overwhelm maintainers if submitted without careful review.
76
-
Our policy exists to ensure that maintainer time is spent on high-quality interactions rather than debugging AI-generated code.
90
+
Processing pull requests and comments
91
+
for MQT Predictor requires significant maintainer time and energy.
92
+
Sending unreviewed AI output to open-source projects shifts the burden of
93
+
verifying correctness from the contributor to the maintainer.
94
+
We classify such contributions as "extractive"
95
+
because they consume more community resources than they provide in value.
96
+
97
+
Our **golden rule** is that a contribution should be valuable enough to justify
98
+
the review effort.
99
+
Nadia Eghbal captures this concept in her book
100
+
_[Working in Public](https://press.stripe.com/working-in-public)_:
101
+
102
+
> "When attention is being appropriated,
103
+
> producers need to weigh the costs and benefits of the transaction.
104
+
> To assess whether the appropriation of attention is net-positive,
105
+
> it's useful to distinguish between _extractive_
106
+
> and _non-extractive_ contributions.
107
+
> Extractive contributions are those where the marginal cost of reviewing
108
+
> and merging that contribution is greater than the marginal benefit to the
109
+
> project's producers.
110
+
> In the case of a code contribution,
111
+
> it might be a pull request that's too complex or unwieldy to review,
112
+
> given the potential upside." — Nadia Eghbal
113
+
114
+
Before AI tools became widespread,
115
+
open-source project maintainers would often review all changes sent to the
116
+
project simply because submitting a pull request was a sign of interest from a
117
+
potential long-term contributor.
118
+
However, AI tools now allow the rapid generation of large volumes of code,
119
+
which can easily overwhelm maintainers if submitted without careful review.
120
+
Our policy exists to ensure
121
+
that maintainer time is spent on high-quality interactions rather than debugging
122
+
AI-generated code.
77
123
78
124
### Sustainable Open Source
79
125
80
-
The Munich Quantum Toolkit (MQT) is committed to remaining free, open-source, and permissively licensed.
81
-
We want to build a welcoming community where aspiring quantum software engineers can learn and grow.
126
+
The Munich Quantum Toolkit (MQT) is committed to remaining free, open-source,
127
+
and permissively licensed.
128
+
We want to build a welcoming community
129
+
where aspiring quantum software engineers can learn and grow.
82
130
Reviewing contributions is a key part of this mentorship.
83
131
84
-
However, to keep the project sustainable, we must prioritize non-extractive contributions.
85
-
By thoroughly reviewing and understanding your AI-assisted code before submission, you ensure that your contribution is a net positive for the project.
86
-
This helps us maintain a healthy ecosystem where both the software and its contributors can thrive.
132
+
However, to keep the project sustainable,
133
+
we must prioritize non-extractive contributions.
134
+
By thoroughly reviewing and understanding your AI-assisted code
135
+
before submission, you ensure that your contribution is a net positive
136
+
for the project.
137
+
This helps us maintain a healthy ecosystem where both the software
138
+
and its contributors can thrive.
87
139
88
140
## Prohibited Uses
89
141
90
-
-**"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.
91
-
-**Spam**: Do not use AI to generate low-quality or repetitive comments/reviews ("AI Slop").
92
-
-**Unreviewed Code**: Submitting code that you, as a human, have not reviewed and tested yourself.
142
+
-**"Good First Issues"**:
143
+
Do not use AI tools to solve issues labeled as "good first issue".
144
+
These are intended as learning opportunities for new contributors.
145
+
Automating them defeats the purpose.
146
+
-**Spam**: Do not use AI to generate low-quality or repetitive comments/reviews
147
+
("AI Slop").
148
+
-**Unreviewed Code**: Submitting code that you, as a human,
149
+
have not reviewed and tested yourself.
93
150
94
151
## Summary
95
152
96
-
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.
97
-
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.
153
+
We want to foster a welcoming community where developers can learn and grow.
154
+
AI tools can be great for productivity,
155
+
but they should not replace critical thinking or the learning process.
156
+
If a maintainer judges that a contribution relies too heavily on unverified AI
157
+
generation or lacks sufficient human understanding ("extractive contribution"),
158
+
we may request that you revise it or close the PR.
98
159
99
160
---
100
161
101
-
Parts of this guide were inspired by or adapted from the contribution guidelines of
162
+
Parts of this guide were inspired by
163
+
or adapted from the contribution guidelines of
102
164
103
165
-[Astral],
104
-
-[Qiskit],
105
-
-[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].
106
-
107
-
with the help of Gemini 3 Pro (Preview). The links above serve as attribution.
166
+
-[Qiskit], and
167
+
-[LLVM], including the sources therein, such as
168
+
[Fedora Council Policy Proposal: Policy on AI-Assisted Contributions (fetched 2026-03-12)][fedora],
169
+
which is licensed under the
170
+
[Creative Commons Attribution 4.0 International License][cca],
![mqt-app[bot]](https://avatars.githubusercontent.com/in/1532480?v=4&size=40){kind=avatar}
0 commit comments