docs: Various updates related to the AI policy (#5116)

I was reminded by Eric Enderton that we should mention and cross
reference the recently-added AI policy docs in other places, since it
can easily be overlooked now, buried in the docs directory.

* Mention it in the pull request template's checklist.
* In the CONTRIBUTING guide.
* Briefly mention in the main README in the list of important
documentation for developers.
* A few very minor touch-ups and wordsmithing in other areas, no
substantive changes.

Also, responding to comments at the OSL TSC meeting this week, I added
a brief section explaining that we don't have any specific guidance for
how AI tools should or shouldn't be used for "artistically creative"
work, since this project repo doesn't really house such things. This
is mostly for the benefit of other projects that may use our policy
document as inspiration, to warn them that they may have issues that
need policy guidance but that we do not address.

Signed-off-by: Larry Gritz <lg@larrygritz.com>

Author: lgritz

.github/PULL_REQUEST_TEMPLATE.md

@@ -19,16 +19,21 @@
 
 <!-- Put an 'x' in the boxes as you complete the checklist items -->
 
-- [ ] I have read the [contribution guidelines](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/CONTRIBUTING.md).
-- [ ] I have updated the documentation, if applicable. (Check if there is no
-  need to update the documentation, for example if this is a bug fix that
-  doesn't change the API.)
-- [ ] I have ensured that the change is tested somewhere in the testsuite
-  (adding new test cases if necessary).
-- [ ] If I added or modified a C++ API call, I have also amended the
-  corresponding Python bindings (and if altering ImageBufAlgo functions, also
-  exposed the new functionality as oiiotool options).
-- [ ] My code follows the prevailing code style of this project. If I haven't
-  already run clang-format before submitting, I definitely will look at the CI
-  test that runs clang-format and fix anything that it highlights as being
-  nonconforming.
+- [ ] **I have read the guidelines** on [contributions](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/CONTRIBUTING.md) and [code review procedures](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/docs/dev/CodeReview.md).
+- [ ] **I have read the [Policy on AI Coding Assistants](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/docs/dev/AI_Policy.md)**
+  and if I used AI coding assistants, I have an `Assisted-by: TOOL / MODEL`
+  line in the pull request description above.
+- [ ] **I have updated the documentation** if my PR adds features or changes
+  behavior.
+- [ ] **I am sure that this PR's changes are tested in the testsuite**.
+- [ ] **I have run and passed the testsuite in CI** *before* submitting the
+  PR, by pushing the changes to my fork and seeing that the automated CI
+  passed there. (Exceptions: If most tests pass and you can't figure out why
+  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
+  any failures seem entirely unrelated to your change; sometimes things break
+  on the GitHub runners.)
+- [ ] **My code follows the prevailing code style of this project** and I
+  fixed any problems reported by the clang-format CI test.
+- [ ] If I added or modified a public C++ API call, I have also amended the
+  corresponding Python bindings. If altering ImageBufAlgo functions, I also
+  exposed the new functionality as oiiotool options.

CONTRIBUTING.md

@@ -1,3 +1,7 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenImageIO Project. -->
+
+
 Contributing to OpenImageIO
 ===========================
 
@@ -78,6 +82,26 @@ If confidentiality precludes a public question or issue for any reason, you
 may contact us privately at [security@openimageio.org](security@openimageio.org).
 
 
+Policy on AI Tools
+------------------
+
+Please read our [Policy on AI Coding Assistants](docs/dev/AI_Policy.md)
+before contributing or particpating in the project in any way mediated by "AI"
+assistants.
+
+High-level summary:
+- 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).
+- Interact with the project and community yourself, not by agent.
+- Disclose what tools you used and how. At a minimum, we require an
+  "Assisted-by: TOOL/MODEL" line in the commit comments and PR description.
+- Don't waste maintainer's time with low quality PRs.
+
+Please do read the whole [Policy on AI Coding Assistants](docs/dev/AI_Policy.md)
+for all the details.
+
+
 Contributor License Agreement (CLA) and Intellectual Property
 -------------------------------------------------------------
 
@@ -238,33 +262,33 @@ repository. The protocol is like this:
 your own repository on GitHub, and then clone it to get a repository on your
 local machine.
 
-1. Edit, compile, and test your changes. Run clang-format (see the
+2. Edit, compile, and test your changes. Run clang-format (see the
 instructions on coding style below).
 
-1. Push your changes to your fork (each unrelated pull request to a separate
+3. Push your changes to your fork (each unrelated pull request to a separate
 "topic branch", please).
 
-1. Make a "pull request" on GitHub for your patch.
+4. Make a "pull request" on GitHub for your patch.
 
-2. If your patch will induce a major compatibility break, or has a design
+5. If your patch will induce a major compatibility break, or has a design
 component that deserves extended discussion or debate among the wider OIIO
 community, then it may be prudent to email oiio-dev pointing everybody to
 the pull request URL and discussing any issues you think are important.
 
-1. All pull requests automatically launch CI jobs on GitHub Actions to
+6. All pull requests automatically launch CI jobs on GitHub Actions to
 ensure that the build completes and that the tests suite runs correctly, for
 a variety of platform, compiler, library, and flag combinations. The status
 of the CI tests for your PR will be displayed on the GitHub PR page. We will
 not accept PRs that don't build cleanly or pass the existing testsuite.
 
-1. The reviewer will look over the code and critique on the "comments" area.
+7. The reviewer will look over the code and critique on the "comments" area.
 Reviewers may ask for changes, explain problems they found, congratulate the
 author on a clever solution, etc. But until somebody says "LGTM" (looks good
 to me), the code should not be committed. Sometimes this takes a few rounds
 of give and take. Please don't take it hard if your first try is not
 accepted. It happens to all of us.
 
-1. After approval, one of the senior developers (with commit approval to the
+8. After approval, one of the senior developers (with commit approval to the
 official main repository) will merge your fixes into the main branch.
 
 Please see the [Code Review](docs/dev/CodeReview.md) document for more

README.md

@@ -144,6 +144,8 @@ pull request (PR) mechanism.
   description of the major classes and their relationships.
 * [CONTRIBUTING](CONTRIBUTING.md) has detailed instructions about the
   development process.
+* [AI Policy](docs/dev/AI_Policy.md) decribes our policies on AI coding
+  assistance tools.
 * [ROADMAP](docs/ROADMAP.md) is a high-level overview of the current
   development priorities for the next annual release, expected in September,
   2024.

docs/dev/AI_Policy.md

@@ -1,5 +1,5 @@
-Proposed OpenImageIO Policy on AI Coding Assistants
-===================================================
+Policy on AI Coding Assistants
+==============================
 
 - Initial policy merged 23-Mar-2026
 
@@ -8,11 +8,12 @@ Use of "AI coding assistants" is permitted on this project, with the following
 guidelines and principles.
 
 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.
+- 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).
 - Interact with the project and community yourself, not by agent.
-- Disclose what tools you used and how.
+- Disclose what tools you used and how. At a minimum, we require an
+  "Assisted-by: TOOL/MODEL" line in the commit comments and PR description.
 - Don't waste maintainer's time with low quality PRs.
 
 The long version:
@@ -147,6 +148,17 @@ This AI tool use policy is not meant to encompass cases such as:
 - Reviewing your own code for mistakes prior to submitting a PR (as long as it
   isn't making the 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:
@@ -155,5 +167,4 @@ Our policy has been informed and inspired by the following efforts in other comm
 - [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)
 - 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/)
-
-
+- [GitHub Blog: Rethinking open source mentorship in the AI era](https://github.blog/open-source/maintainers/rethinking-open-source-mentorship-in-the-ai-era/)