[PROJ] More restrictive LLM policy - like in GDAL

[Greg Troxel]

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.