[PROJ] More restrictive LLM policy - like in GDAL

[Kurt Schwehr]

Javier,

What exactly are you voting on?

For those not keeping up, please also see this discussion:

https://lists.osgeo.org/pipermail/gdal-dev/2026-October/061758.html

I personally think both PROJ and GDAL need detailed AGENTS.md files to help
control the situation and to let AI review tools better help all who use
LLM agents in any part of their workflow.

-Kurt


On Sun, Oct 18, 2026 at 7:55 AM Javier Jimenez Shaw via PROJ <
proj at lists.osgeo.org> wrote:

> Let's vote
>
> I start with my +1
> Javier
>
> On Fri, 16 Oct 2026, 10:57 Kristian Evers, <kristian at evers.dev> wrote:
>
>> Thanks for starting this discussion, Javier! I think everyone that
>> follows the activity on GitHub will have been overwhelmed by recent
>> activity. I certainly have. It’s’ clear to me that we need to change
>> something but it is not clear to me what the best way forward is. Having
>> given the topic some though over the last week I think my priorities are as
>> follows:
>>
>> * Community building
>> * Human interactions
>> * Avoiding maintainer burnout
>> * Producing a useful software package
>>
>> At the moment we are struggling in the three first bullets. In particular
>> regarding human interaction. There are quite a few cases where you can
>> rightfully doubt if a human was even involved at all. Really discouraging.
>> The influx of new dubious contributors is driving maintainer burnout at the
>> moment and is not doing wonders for the community either. That said, access
>> to LLM tools has also lowered the barrier for entry[0] to our community
>> which can be seen in the increased number of contributions in the
>> cartographic parts of PROJ. An area that hasn't seen much focus over the
>> last few years. The LLMs are helping bridge the gap between web-based
>> cartography and our ancient ways of C and C++. I think it is fantastic to
>> see some of the innovation in the Javascript-space find its way into PROJ
>> but it is not worth anything if it causes the regular maintainers to burn
>> out.
>>
>> I can agree to adopt the GDAL policy but I don’t think it will fix
>> everything. I expect we will end up spending quite some time policing the
>> policy and new contributors trying to circumvent it. Probably that’s better
>> than doing nothing but still not particularly fun.
>>
>> Let’s finish this debate at the policy first and once that is settled I
>> would like to propose a few extra ideas on how to avoid bot accounts and
>> increasing community engagement. Stay tuned.
>>
>> /Kristian
>>
>>
>> [0] Two-edged sword, I know.
>>
>> On 15 Oct 2026, at 19.45, Javier Jimenez Shaw via PROJ <
>> proj at lists.osgeo.org> wrote:
>>
>> Hi
>>
>> Recently there has been a relative explosion of PRs (and issues) in PROJ.
>> I would say that many of them were LLM generated, by people (well, probably
>> not people) that do not know the project, do not care about it, and very
>> likely do not have any connection with it. Just to get some "points" as
>> contributors I guess.
>> I don't want to know how much energy and tokens they burned for such PRs
>> and issues.
>> You can go to the repository and have your own opinion.
>>
>> I created this PR that is a copy of the GDAL AI policy:
>> https://gdal.org/en/stable/community/ai_tool_policy.html
>>
>> I don't know if it will keep slope code out of PROJ, but it is another
>> step.
>> https://github.com/OSGeo/PROJ/pull/4912
>>
>> Cheers
>> Javier.
>>
>>
>> _______________________________________________
> 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/20261018/e9cea7d5/attachment.htm>