LLM policy

Fri Jun 19 09:06:26 PDT 2026

Alex,

Thanks for pointing all those things out.  I agree with all of them.

There are two things we are thinking of:

1.	Yes clarify our code of conduct 
2.	To Greg’s point who sadly left presumably because of irreconcilable differences, and to strk’s conclusion, I think it’s worthwhile to make an LLM policy and I’ve been reading the ones Greg pointed out to see what we like and don’t like https://lists.osgeo.org/pipermail/postgis-devel/2026-June/030773.html

We have decided that yes ultimately the human is responsible for the actions of the LLM, but we also want to not discourage people from using them and are more concerned with setting up best practices of using LLM as best we can by experimenting with them ourselves to make it less likely that a user will inadvertently break our code of conduct.

We are still experimenting with what do we consider good practices of using an LLM and as you can see  <mailto:strk at kbt.io> @Sandro Santilli set up a repo here for that - https://gitea.osgeo.org/postgis/postgis-ai

The idea being something like, we may decide not to allow LLM generated from new users, unless they’ve played at least once in our postgres-ai playpen.  I think that will help curve drive-by LLM pull requests, which we haven’t gotten any of yet to my knowledge aside from the ones Darafei has been generating.

Also  we have decided that any contribution largely written by an LLM should have an Assisted By: <org> Model .  

Case in point - https://gitea.osgeo.org/postgis/postgis_tiger_geocoder/pulls/25

I don’t know if anyone agrees with me or not, but I don’t want links back to the site of the org, because then it would just feel like marketing that org to others.  We were torn with Assisted By because:

a.	Feels like just marketing
b.	It’s the honest thing to do though and will flag that yes we need to pay more attention to this PR because of generation of poorer code by LLM (which I expect to improve with time)
c.	It could get noisy as Darafei mentioned if a core contributor is using it a lot for some tasks.  Strk had suggested maybe contributors that want to use an LLM a lot, have the commits done by an ai proxy e.g. if strk’s ai was writing the code, it would be strk-ai (as the author), but of course strk would be the one to merge it and be responsible for having merged it.  Then in that case, strk-ai bio would show the details of models used etc.
d.	At what point do you say you don’t need to disclose.  E.g. If I use a search AI mode on a search engine to write a line of code I am struggling with, do I need to say Assisted By?  Cause I would never write that when I do a seach engine search to find someone who has had the same problem and use that person’s recipe.  I wouldn’t write “Assisted-By: DuckDuckGo” in my commit notes, though I may provide a link to where I got the answer in the pull request description.

Darafei has been experimenting with LLMs and he did say it is taking him a bit of time to review some of these.  So we might put another restriction like, No big patches period, 

unless you have made contributions in the past, cause we don’t have faith in you yet that you can review your code.  If a core contributor does it we of course expect the contributor to have thoroughly reviewed before applying and thus can commit any size.

So that would be a simple reject and we can even auto do that – any patch written by someone for the first time can’t be longer than X characters total.  

That would force users to solve simpler problems before they try to solve larger ones and prove that they are not just a drive-by patcher.

From: Alexandre Lessard <alexandre.lessard at mapgears.com> 
Sent: Friday, June 19, 2026 10:22 AM
To: postgis-devel at lists.osgeo.org
Subject: Re: LLM policy

After re-reading the Code of Conduct, I see how this could cover any issue with LLMs, but now because of :

PostGIS welcomes and encourages participation by everyone. We are committed to being a community that everyone feels good about joining, and we will always work to treat everyone well. No matter how you identify yourself or how others perceive you: we welcome you.

but because of the Specific guidelines, especially those points :

*	Be empathetic, welcoming, friendly, and patient; "At the moment, LLMs are welcoming, friendly, and patient, but empathetic isn't part of what they can do."
*	Be inquisitive; "LLMs aren't inquisitive by default, they need to be properly prompted to do so."
*	Be concise; "This is the biggest pain with open source projects right now, they are really verbose and are using a lot of the efforts of reviewers." 
*	Step down considerately; "That is often an issue still, where either they don't acknowledge an issue, or they just repeat the same thing and pretend it's solved."

The biggest issue that needs to be resolved here is, who is the entity breaking the code of conduct when this happens? Is it the human that connected the LLM to the Repository, the agent instance, the agent software/version, the agent developers, the LLMs, the LLM flavour, the LLM Flavour and version, or the developers of the LLM. And how breaking the Code of Conduct is going to be applied?

I believe that if those are clearly addressed to clear the confusion, the code of conduct would be able to resolve any issue with humans, corporations or LLM.

Thanks,

Alex.

P.S. To clear any ambiguities about my opinions, I do not like LLMs nor the generative AI industry right now, I believe the it can be a really useful tool in the hands of someone qualified, but I still find the ethical issue of how they acquired their, data and how energy and hardware hungry these things are. But I'm also of the opinion that if someone decides to use them, they should do it properly and not be a net negative to society.

On Fri, 19 Jun 2026 at 07:02, Greg Troxel <gdt at lexort.com <mailto:gdt at lexort.com> > wrote:

I've stopped being maintainer of the pkgsrc package and am signing off
the list.  I wish you well in postgis development!

-- 

Alexandre Lessard

DevOps - Mapgears

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260619/fe1f472e/attachment-0001.htm>