Add draft AI contribution policy

[selimnairb]

Resolves #148. Open for comments for 30 days.

[schwehr]

I look forward to seeing peoples' comments.

Note for the following: I'm on the boards for PROJ and GDAL. You will see me as "KurtS" in the GDAL voting.

GDAL, GRASS, and QGIS all have very related policies, e.g. the GDAL RFC 111 references these:

• GRASS GIS policy: https://github.com/OSGeo/grass/blob/main/CONTRIBUTING.md
• QGIS policy: Add QEP 408: AI tool use policy qgis/QGIS-Enhancement-Proposals#363

However, I haven't looked into the discussion at OSGeo that was linked from this post:

https://www.osgeo.org/foundation-news/ai-in-osgeo-projects-notes-from-the-timisoara-bof/

For those wanting to see the GDAL discussions and results, take a look at these. Note that there have been 2 iterations so far, and I expect the policy to keep changing.

• gdal#13880 - RFC111: AI/LLM tool policy
• gdal#14500 - RFC111 AI/LLM tool policy: significant revision, limiting drastically their use
• https://lists.osgeo.org/pipermail/gdal-dev/2026-February/thread.html Threads:
  • Call for review: RFC111: AI/LLM tool policy
  • Motion: adopt RFC111: AI/LLM tool policy

The resulting documents:

• RFC 111: Add a AI/LLM tool policy
• LLM tool policy

And this is particularly interesting:

OSGeo/gdal@14ffe80

Our initial feedback from receiving AI tools based contributions is that they
have the effect of making maintainers more grumpy than usual. As fixing human
behavior to play nicely with AI will involve natural selection over many generations,
be prepared for not getting a very warm welcome if you misuse those tools.
You have been warned!

I've personally seen the quality of the LLM based tool outputs run the whole range of quality spectrum.

[giumas]

I suggest rewording this title to: “AI Tool Use Policy for the Bathymetric Attributed Grid (BAG) Project” to make immediately clear that BAG is the project and AI tool use is the subject of the policy.

[giumas]

I support the overall human-in-the-loop principle and contributor accountability. My comments are mostly intended to clarify the scope and application of the policy.

[giumas]

I fully support transparency, but “substantial amounts” seems difficult to interpret consistently. Thus, it might help clarifying that routine assistance such as code completion, debugging suggestions, or copy-editing does not normally require disclosure, whereas generation of significant portions of the submitted implementation/documentation does.

[giumas]

As AI assistance becomes increasingly integrated into development environments, distinguishing between “AI-generated” and “human-generated” content may also become difficult. I wonder whether the policy could focus more strongly on accountability and validation, while requiring disclosure only where AI played a material role in producing the submitted contribution.

[giumas]

Typo: "adapted"

[giumas]

“vibe-coded” is a bit too informal (and somewhat ambiguous) for an official policy. What about: "This project does not accept AI-generated contributions that have not been adequately reviewed, understood, and validated by the contributor"?

[giumas]

I believe that “take action” is a bit too broad. Are we intentionally including CI bots, Dependabot, linters posting annotations, automated formatting/release bots, etc.?
I would recommend defining the scope more explicitly, for example as “generative AI agents producing substantive contributions or review comments,” while excluding conventional project automation and maintainer-approved bots.

[giumas]

Using an LLM to understand reviewer feedback can actually be educational. So I would expand a bit this statement to something like: "Simply passing maintainer feedback to an LLM and submitting its response without understanding or evaluating the resulting changes does not support contributor growth or sustainable project maintenance."