[PROJ] More restrictive LLM policy - like in GDAL

[David Hoese]

Hi everyone,

> what is submitted needs to be 0% LLM and 100% understood

I'm not sure I have the full historical context of all of this and I'm also
primarily a user of PROJ and have only contributed minor things in the past
(mostly bug reports). I'm also someone who has been using Claude way too
much lately (for non-PROJ work) and have definitely generated a couple
large PRs that beyond my human-written paragraph at the top may even
include Claude's summary of the changes in the description. I do this
mostly only on my projects where I'm a maintainer, but have also done it on
some projects that I'll never be able to hold the internal structure of in
my head. I always try to review all the code so I understand what is being
changed, but as far as the bigger picture in the library I'm not sure I'll
ever get that type of understanding. Even in my purely human contributions
to libraries that aren't my own I don't always have the big picture for
what I'm submitting. That said, I agree that it is scary and overwhelming
to get purely AI PRs.

However, I think there's a use case that is hard to guard against from a
user-now-contributor point of view: Sometimes you're working on something
and ask AI to debug a test failure. This might result in a bug report, but
it is also really easy to come up with a solution. For those solutions, it
is hard not to submit that as a PR. I agree that the contributor should
understand what was changed, but once that has happened does that mean the
solution is 0% LLM or 100% LLM or somewhere in between? And what is
acceptable? If I have Claude generate a solution, I understand what was
changed, I have Claude change things that I don't like or that could be
done differently but Claude is still making the changes, is that allowed?
Once a solution has been seen from Claude for a project that does not allow
AI PRs, even if I understand the changes, what do I do then?

I think having a purely human-written PR description is the best I've been
able to do lately in these situations both as a contributor and as a
maintainer. The contributor's understanding has to come through in the
description. That said, pasting AI benchmark tables or comparison images or
whatever also ends up being really helpful. I'm not sure how to quantify "I
used AI as a tool" versus "No human was involved in this coding loop".

Dave

On Wed, Oct 21, 2026 at 7:19 AM Greg Troxel via PROJ <proj at lists.osgeo.org>
wrote:

> Alan Snow via PROJ <proj at lists.osgeo.org> writes:
>
> > I have experienced the two-edged sword Kristian mentioned. I have seen
> the
> > barrier to entry lowered for contributors as well as an increase in the
> bot
> > accounts.
> >
> > I have the same priorities Kristian mentioned as well:
> >
> > * Community building/human interactions
> > * Avoiding maintainer burnout
> > * Producing a useful software package
> >
> > I suggest we divide this discussion into two topics:
> >
> > - How do we prevent bots from overwhelming PROJ?
>
> The biggest issue is "how do we change culture so that anyone with repo
> access feels that they should immediately hit close on an issue or PR
> that is outside the guidelines".  Only that will "protect" the
> community, from agent-generated anything, and overly verbose LLMish text
> both.
>
> > - How do we guide new contributors who who might not have been able to
> > contribute code without AI/LLM usage? (i.e. guide developers to
> contribute
> > in a maintainer friendly manner)
>
> I don't think there should be a ban on using LLM to understand.  But
> what is submitted needs to be 0% LLM and 100% understood.  That means
> contributors have to learn enough to understand what they are changing.
> If that's not what happens, they're a meat proxy, and it's asking the
> maintainers to do the work of turning maybe-confused too-verbose LLM
>
> Asking how we support "new contributors who don't have the capacity to
> contribute without LLM" pre-supposes that the project should accept LLM
> output to enable that kind of "contribution".   The consensus seems to
> be that LLM-generated text in PRs and issues is a burden, not a
> contribution.
>
> People can contribute in non-code ways.  Testing, bug reports, comments
> abotu what's unclear in docs, etc.  As long as that's human-generated,
> it's a contribution.
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20261021/9fe1ef89/attachment-0001.htm>