Add AI Policy

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,3 +1,12 @@
+**If using AI assistance to author the PR, make sure you're acting within our [AI Policy](https://opentimelineio.readthedocs.io/en/latest/tutorials/ai-policy.html)**
+
+A reminder on things to do when using AI assistance:
+
+- You are strongly encouraged to disclose AI assistance via `Assisted-by: TOOL / MODEL` in the PR description.
+- Do not use AI assistance to address a 'good first issue'.
+- A human must always be in the loop, and is the responsible party for the contents of a PR (including fully understanding and being able to explain, defend, and modify it in response to review comments).
+- Humans should interact with the project and community directly, not agents.
+
 **Link the Issue(s) this Pull Request is related to.**
 
 If there is an associated issue, link it in the form:

README.md

@@ -148,6 +148,8 @@ Developing
 
 If you want to contribute to the project, please see: https://opentimelineio.readthedocs.io/en/latest/tutorials/contributing.html
 
+Also please review our [AI Policy](https://opentimelineio.readthedocs.io/en/latest/tutorials/contributing.html#ai-coding-tools) if using AI coding assistance tools.
+
 You can get the latest development version via:
 
 `git clone git@github.com:AcademySoftwareFoundation/OpenTimelineIO.git --recursive `

docs/index.rst

@@ -37,6 +37,7 @@ Tutorials
    :caption: Tutorials
 
    tutorials/adapters
+   tutorials/ai-policy
    tutorials/architecture
    tutorials/contributing
    tutorials/feature-matrix

docs/tutorials/adapters.md

@@ -29,7 +29,6 @@ These adapters are supported by the broader OpenTimelineIO community. While the
 
 Below are some other adapters that may be useful to some users:
 
-- [kdenlive](https://invent.kde.org/multimedia/kdenlive-opentimelineio)
 - [fcpx_xml](https://github.com/OpenTimelineIO/otio-fcpx-xml-adapter)
 - [hls_playlist](https://github.com/OpenTimelineIO/otio-hls-playlist-adapter)
 

docs/tutorials/ai-policy.md

@@ -0,0 +1,169 @@
+Policy on AI Coding Assistants
+==============================
+
+- Revised: 12-Sep-2026
+
+
+Use of "AI coding assistants" is permitted on this project, with the following
+guidelines and principles.
+
+Summary of our core values:
+- Human must always be in the loop, and is the responsible party for
+  the contents of a PR (including fully understanding and being able
+  to explain, defend, and modify it in response to review comments).
+- Humans should interact with the project and community directly, not agents.
+- You are strongly encouraged to disclose what tools you used and how. At a
+  minimum, we request an "Assisted-by: TOOL / MODEL" line in the PR description.
+- Don't waste maintainer's time with low quality PRs.
+
+The long version:
+
+## Human authorship and interaction with the project
+
+**The human making a PR is considered the author** and is fully responsible
+for the code they submit.
+
+**No PRs should be submitted, reviewed/merged, or deployed without a human
+fully in the loop.** You may use agents locally to help you write code (and
+docs, tests, etc.), but you may not use agents to autonomously interact with
+the project community. Submit your own PRs, write your own discussion
+comments, respond to community members in your own words, approve or reject
+code in review using your own brain.
+
+Code autonomously submitted without an identifiable human author and
+responsible party will be immediately closed, and the account associated with
+the submission may be banned from future project participation.
+
+**DO NOT "vibe code."** This term refers to a pure prompt-to-behavior cycle
+where the human accepts un-inspected code based on the program behavior alone.
+We don't want this. Code that must be maintained by the project should be
+truly understood. Project code is ideally the result of discussion / pair
+programming between the author and assistant, but even if the machine is doing
+most of the work, all code should be approved and fully understood by the
+author prior to PR submission.
+
+## Professionalism and quality
+
+**The usual high quality level of PRs should be maintained regardless of tools
+used.** This includes not only code, but also the design, testing, PR
+preparation, and the author's ability to explain and defend the code and
+respond to questions and requests for changes. We never want to hear "but the
+AI..." as an excuse for anything.
+
+**PRs should always be reviewed and approved by someone other
+than their author if at all possible.** This is especially true of code with
+machine-generated components, because of the additional risk that the
+submitter/operator may not fully understand what they did not write
+themselves. This is part of the reason for AI tool disclosure -- to ensure
+that another pair of eyes is on it. AI code review may be requested for
+additional input, but the AI cannot give "approval", nor merge code itself.
+
+**Even when using a coding assistant to write the code, you are strongly
+encouraged to write your own PR description, in your own words, if for no
+other reason than to force yourself to understand the code well enough to
+describe it to others.**
+
+## Disclosure
+
+**Disclosure is strongly encouraged.** Patches that were written with the aid of AI
+coding assistants should have, at a minimum, the following line in the PR description body:
+
+    Assisted-by: TOOL / MODEL
+
+We especially request this when an LLM materially helped with the change
+(drafted code, helped design the approach, found the bug, suggested the
+specific fix, etc.). You may omit for any of the reasons listed in the
+"Exceptions" section below.
+
+If you used the coding assistant in an unusual way that others could learn
+from, feel free to briefly say how you used the tool. But this is not required
+and we understand that it's often infeasibly difficult to describe accurately
+in any detail.
+
+## Intellectual Property
+
+Regardless of how the code came to be -- from your head alone, from a friend,
+from Stack Overflow, from a blog post, from reading other code bases, or from
+a coding assistant -- we expect the terms of the
+[DCO](https://developercertificate.org/) and CLA to apply, and for the author
+to take reasonable care that code is not copied from a source with an
+incompatible license.
+
+You may find that your confidence about complying with the DCO+CLA depends on:
+
+- If you provided a detailed specification and how much you edited or guided
+  the results yourself.
+- Whether you are modifying or extending existing code versus writing large
+  amounts of entirely new code.
+- The degree to which the generated code seems to fit into our structure and
+  idiomatic style, and therefore seems unlikely to be copied from elsewhere.
+- Whether your tool has guardrails to prevent answers that are too similar to
+  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/).
+
+## Extractive submissions
+
+**Maintainer time and attention are precious commodities**, and use of coding
+assistants is not an excuse to submit poor PRs or to externalize costs onto
+maintainers/reviewers (such as responsibility for understanding, testing, or
+fixing PRs that the human author does not have a full understanding of). 
+
+Maintainers are free to take counter-measures against submitters of sub-par
+PRs, or other violations of this policy, up to and including banning habitual
+abusers from future participation in the project.
+
+**We discourage use of AI tools to fix GitHub issues labeled as "good first
+issue" or for "Dev Days" work.** Cultivating and educating new contributors is
+important, and as such, we do not want people to swoop in and use automated
+tools to trivially solve tasks that were curated specifically for somebody to
+actually learn from. We expect each developer to implement at most one "good
+first issue" per Dev Days occasion, and we encourage you to solve the problem
+with your own brain to maximize the learning experience.
+
+## Exceptions
+
+This AI tool use policy is not meant to encompass cases such as:
+- "Smart auto-complete", spell-checking, grammar checking, or other uses that
+  aren't really contributing substantively to authorship.
+- Purely mechanical assistance and light refactoring, such as moving code
+  around or renaming things, enforcing formatting or coding style -- the
+  kind of thing that IDEs could do for you even before LLMs.
+- Use of LLMs to explain code or learn about the codebase, answer basic
+  programming questions, help with background research, or audit the code
+  for bugs that are subsequently confirmed and fixed by people.
+- Language translation for non-fluent English speakers or other accessibility
+  accommodations.
+- Trivial or de-minimis fixes such as fixing a typo, obviously wrong variable
+  use, etc.
+- Reviewing your own code for mistakes prior to submitting a PR (as long as it
+  isn't making substantive fixes for you).
+
+
+## Creative contributions -- out of scope
+
+This project repository contains code for tools, and their documentation. We
+don't really directly host any artistically creative work here, so we have not
+addressed additional policy issues that might come up in such a context.
+
+If you are representing a different project that is using this document for
+guidance or inspiration for your own policies, please be aware that you may
+have needs that are not covered by these policies but deserve well-crafted
+guidance.
+
+## References and inspiration
+
+Our policy has been informed and inspired by the following efforts in other communities:
+
+- [OpenImageIO AI Tool Policy](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/docs/dev/AI_Policy.md) -- we directly forked this as our starting point.
+- [LLVM AI Tool Policy](https://llvm.org/docs/AIToolPolicy.html)
+- [Fedora Project policy on AI-assisted contributions](https://communityblog.fedoraproject.org/council-policy-proposal-policy-on-ai-assisted-contributions/)
+- [Linux Foundation policy on Generative AI](https://www.linuxfoundation.org/legal/generative-ai)
+- [Rust policy on rejecting burdensome PRs](https://github.com/rust-lang/compiler-team/issues/893)
+- [GitHub Blog: Rethinking open source mentorship in the AI era](https://github.blog/open-source/maintainers/rethinking-open-source-mentorship-in-the-ai-era/)
+- [The Leiden Declaration on AI](https://leidendeclaration.ai/) -- from the research mathematics community, but their "Recommendations" section is very relevant. Also see Terence Tao's very readable [Mathematics in the age of AI](https://arxiv.org/abs/2608.16753).
+
+And here is some food for thought about the wisdom of which tasks to
+outsource to machines:
+
+- 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/)
+- [AI Can Write Your Code. It Can’t Do Your Job.](https://terriblesoftware.org/2025/12/11/ai-can-write-your-code-it-cant-do-your-job/)
+

docs/tutorials/contributing.md

@@ -15,6 +15,16 @@ Here are the two possible CLAs:
 * [OTIO_CLA_Corporate.pdf](https://github.com/AcademySoftwareFoundation/OpenTimelineIO/raw/main/OTIO_CLA_Corporate.pdf): please sign this one for corporate use
 * [OTIO_CLA_Individual.pdf](https://github.com/AcademySoftwareFoundation/OpenTimelineIO/raw/main/OTIO_CLA_Individual.pdf): please sign this one if you're an individual contributor
 
+## AI Coding Tools
+
+Please see our [AI Coding Assistant Policy](ai-policy) for guidelines on contributing code developed with AI coding assistance.
+
+Note that **disclosure is strongly encouraged.** Patches that were written with the aid of AI
+coding assistants should have, at a minimum, the following line in the commit
+comment and PR description body:
+
+    Assisted-by: TOOL / MODEL
+
 ## Coding Conventions
 Please follow the coding convention and style in each file and in each library when adding new files.