Skip to content

Commit acb6446

Browse files
lgritzlgritz
committed
admin: Draft policy on use of AI coding assistants (AcademySoftwareFoundation#5072)
Summary of our core values: - Human always in the loop and is the responsible party. - You're still on the hook for fully understanding and standing behind what you submit. - Interact with the project and community yourself, not by agent. - Disclose what tools you used and how. At the very least, have an `Assisted-by TOOL / MODEL` line. - Don't waste maintainer time with low quality PRs. - Try to reserve the curated Dev Days and "Good First Issues" tags for human learning. --------- Signed-off-by: Larry Gritz <lg@larrygritz.com>
1 parent b71777c commit acb6446

1 file changed

Lines changed: 159 additions & 0 deletions

File tree

‎docs/dev/AI_Policy.md‎

Lines changed: 159 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,159 @@
1+
Proposed OpenImageIO Policy on AI Coding Assistants
2+
===================================================
3+
4+
- Initial policy merged 23-Mar-2026
5+
6+
7+
Use of "AI coding assistants" is permitted on this project, with the following
8+
guidelines and principles.
9+
10+
Summary of our core values:
11+
- Human always in the loop and is the responsible party.
12+
- You're still on the hook for fully understanding and standing behind what
13+
you submit.
14+
- Interact with the project and community yourself, not by agent.
15+
- Disclose what tools you used and how.
16+
- Don't waste maintainer's time with low quality PRs.
17+
18+
The long version:
19+
20+
### Human authorship and interaction with the project
21+
22+
**The human making a PR is considered the author** and is fully responsible
23+
for the code they submit.
24+
25+
**No PRs should be submitted, reviewed/merged, or deployed without a human
26+
fully in the loop.** You may use agents locally to help you write code (and
27+
docs, tests, etc.), but you may not use agents to autonomously interact with
28+
the project community. Submit your own PRs, write your own discussion
29+
comments, respond to community members in your own words, approve or reject
30+
code in review using your own brain.
31+
32+
Code autonomously submitted without an identifiable human author and
33+
responsible party will be immediately closed, and the account associated with
34+
the submission may be banned from future project participation.
35+
36+
**DO NOT "vibe code."** This term refers to a pure prompt-to-behavior cycle
37+
where the human accepts un-inspected code based on the program behavior alone.
38+
We don't want this. Code that must be maintained by the project should be
39+
truly understood. Project code is ideally the result of discussion / pair
40+
programming between the author and assistant, but even if the machine is doing
41+
most of the work, all code should be approved and fully understood by the
42+
author prior to PR submission.
43+
44+
### Professionalism and quality
45+
46+
**The usual high quality level of PRs should be maintained regardless of tools
47+
used.** This includes not only code, but also the design, testing, PR
48+
preparation, and the author's ability to explain and defend the code and
49+
respond to questions and requests for changes. We never want to hear "but the
50+
AI..." as an excuse for anything.
51+
52+
**PRs should always be [reviewed](CodeReview.md) and approved by someone other
53+
than their author if at all possible.** This is especially true of code with
54+
machine-generated components, because of the additional risk that the
55+
submitter/operator may not fully understand what they did not write
56+
themselves. This is part of the reason for AI tool disclosure -- to ensure
57+
that another pair of eyes is on it. AI code review may be requested for
58+
additional input, but the AI cannot give "approval", nor merge code itself.
59+
60+
Even when using a coding assistant to write the code, you are strongly
61+
encouraged to write your own PR description, in your own words, if for no
62+
other reason than to force yourself to understand the code well enough to
63+
describe it to others.
64+
65+
### Disclosure
66+
67+
**Disclosure is required.** Patches that were written with the aid of AI
68+
coding assistants must have, at a minimum, the following line in the commit
69+
comment and PR description body:
70+
71+
Assisted-by: TOOL / MODEL
72+
73+
Ideally, to the extent practical, the PR description should also have a brief
74+
description of how the tool was used, including the gist of key prompts or
75+
summarizing the direction of the dialog. A full log is not necessary; a short
76+
summary will do.
77+
78+
There are several reasons for this disclosure/documentation, even though it
79+
will sometimes be inconvenient:
80+
- Reproducibility: We want even automated work to be reproducible by others in
81+
principle, just like a scientific paper.
82+
- Education: We want to actively teach each other what tools, prompts, or
83+
methods are successful at making high quality results for the project.
84+
- Metrics: We would like the ability to look back and compare assisted vs
85+
non-assisted code for things like defect rate (how often were new bugs
86+
introduced or commits needed to be reverted), whether people are more likely
87+
to write comprehensive tests when using assistants, etc.
88+
- Compliance: Many key users and developers are in companies where they need
89+
to disclose how AI tools were used in their work, and in other software that
90+
they use. Let's make it easy for them.
91+
- Insurance: Should future legal decisions radically change the IP status of
92+
AI-generated code, or if particular models are implicated in copyright
93+
violations, we want a way to find out which contributions might need to be
94+
revisited in order to bring the project back into compliance.
95+
96+
### Intellectual Property
97+
98+
Regardless of how the code came to be -- from your head alone, from a friend,
99+
from Stack Overflow, from a blog post, from reading other code bases, or from
100+
a coding assistant -- we expect the terms of the
101+
[DCO](https://developercertificate.org/) and CLA to apply, and for the author
102+
to take reasonable care that code is not copied from a source with an
103+
incompatible license.
104+
105+
You may find that your confidence about complying with the DCO+CLA depends on:
106+
107+
- If you provided a detailed specification and how much you edited or guided
108+
the results yourself.
109+
- Whether you are modifying or extending existing code versus writing large
110+
amounts of entirely new code.
111+
- The degree to which the generated code seems to fit into our structure and
112+
idiomatic style, and therefore seems unlikely to be copied from elsewhere.
113+
- Whether your tool has guardrails to prevent answers that are too similar to
114+
existing code, for example as claimed by [Claude](https://privacy.claude.com/en/articles/10023638-why-am-i-receiving-an-output-blocked-by-content-filtering-policy-error) and [Copilot](https://docs.github.com/en/copilot/how-tos/manage-your-account/).
115+
116+
### Extractive submissions
117+
118+
**Maintainer time and attention are precious commodities**, and use of coding
119+
assistants is not an excuse to submit poor PRs or to externalize costs onto
120+
maintainers/reviewers (such as responsibility for understanding, testing, or
121+
fixing PRs that the human author does not have a full understanding of).
122+
123+
Maintainers are free to take counter-measures against submitters of sub-par
124+
PRs, or other violations of this policy, up to and including banning habitual
125+
abusers from future participation in the project.
126+
127+
**We discourage use of AI tools to fix GitHub issues labeled as "good first
128+
issue" or for "Dev Days" work.** Cultivating and educating new contributors is
129+
important, and as such, we do not want people to swoop in and use automated
130+
tools to trivially solve tasks that were curated specifically for somebody to
131+
actually learn from. We expect each developer to implement at most one "good
132+
first issue" per Dev Days occasion, and we encourage you to solve the problem
133+
with your own brain to maximize the learning experience.
134+
135+
### Exceptions
136+
137+
This AI tool use policy is not meant to encompass cases such as:
138+
- "Smart auto-complete", spell-checking, grammar checking, or other uses that
139+
aren't really contributing substantively to authorship.
140+
- Use of LLMs to explain code or learn about the codebase, answer basic
141+
programming questions, help with background research, or audit the code
142+
for bugs that are subsequently confirmed and fixed by people.
143+
- Language translation for non-fluent English speakers or other accessibility
144+
accommodations.
145+
- Trivial or de-minimis fixes such as fixing a typo, obviously wrong variable
146+
use, etc.
147+
- Reviewing your own code for mistakes prior to submitting a PR (as long as it
148+
isn't making the fixes for you).
149+
150+
### References and inspiration
151+
152+
Our policy has been informed and inspired by the following efforts in other communities:
153+
- [LLVM AI Tool Policy](https://llvm.org/docs/AIToolPolicy.html)
154+
- [Fedora Project policy on AI-assisted contributions](https://communityblog.fedoraproject.org/council-policy-proposal-policy-on-ai-assisted-contributions/)
155+
- [Linux Foundation policy on Generative AI](https://www.linuxfoundation.org/legal/generative-ai)
156+
- [Rust policy on rejecting burdensome PRs](https://github.com/rust-lang/compiler-team/issues/893)
157+
- The METR paper [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
158+
159+

0 commit comments

Comments
 (0)