<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>> what is submitted needs to be 0% LLM and 100% understood</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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".</div><div><br></div><div>Dave</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Oct 21, 2026 at 7:19 AM Greg Troxel via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Alan Snow via PROJ <<a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>> writes:<br>
<br>
> I have experienced the two-edged sword Kristian mentioned. I have seen the<br>
> barrier to entry lowered for contributors as well as an increase in the bot<br>
> accounts.<br>
><br>
> I have the same priorities Kristian mentioned as well:<br>
><br>
> * Community building/human interactions<br>
> * Avoiding maintainer burnout<br>
> * Producing a useful software package<br>
><br>
> I suggest we divide this discussion into two topics:<br>
><br>
> - How do we prevent bots from overwhelming PROJ?<br>
<br>
The biggest issue is "how do we change culture so that anyone with repo<br>
access feels that they should immediately hit close on an issue or PR<br>
that is outside the guidelines".  Only that will "protect" the<br>
community, from agent-generated anything, and overly verbose LLMish text<br>
both.<br>
<br>
> - How do we guide new contributors who who might not have been able to<br>
> contribute code without AI/LLM usage? (i.e. guide developers to contribute<br>
> in a maintainer friendly manner)<br>
<br>
I don't think there should be a ban on using LLM to understand.  But<br>
what is submitted needs to be 0% LLM and 100% understood.  That means<br>
contributors have to learn enough to understand what they are changing.<br>
If that's not what happens, they're a meat proxy, and it's asking the<br>
maintainers to do the work of turning maybe-confused too-verbose LLM<br>
<br>
Asking how we support "new contributors who don't have the capacity to<br>
contribute without LLM" pre-supposes that the project should accept LLM<br>
output to enable that kind of "contribution".   The consensus seems to<br>
be that LLM-generated text in PRs and issues is a burden, not a<br>
contribution.<br>
<br>
People can contribute in non-code ways.  Testing, bug reports, comments<br>
abotu what's unclear in docs, etc.  As long as that's human-generated,<br>
it's a contribution.<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>