<div dir="ltr">Hi,<br><br>I believe AIs are covered by existing diversity statement of code of conduct:<br><br><a href="https://postgis.net/community/conduct/#diversity-statement">https://postgis.net/community/conduct/#diversity-statement</a><br>> 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.<br><br>I don't think it is limited to "humans only" (assume LLMs are humans with brain prosthetics if you wish - there's still human beings behind them at this point). I do not think there is a need for a deeper policy at this time. AI code reviews, AI security reports by various vendors have also been useful and strengthened PostGIS in the last couple years.<div><br></div><div>I've been to communities in the past where my non-british english got me into the "not human enough" category so I would insist that measuring humanness of contributors is not a good path to follow. A spambot is not welcome because of spam, not because of bot.<br><br>For other projects avoiding AI/LLM: I believe most pain is coming from under-documenting developer workflows and standards, thus gatekeeping from newbie people (who give up) and AIs (who don't give up, but you may not like where they end up without guidance). I continuously make sure PostGIS contributions are newbie-friendly (thanks Regina for showing me that way) and it seems that also makes AI agents' involvement natural and non-annoying.<br><br>Thanks,<br>Darafei.<br><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2026 at 2:16 PM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</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">A human recently told me to make this a new thread :-)<br>
<br>
Recently qgis and gdal have discussed and adopted policy about<br>
LLM-generated content in mostly PRs.<br>
<br>
After "human must be in control and really understand" was agreed to in<br>
gdal, somewhat (in my fuzzy view) as a compromise between the "just no"<br>
camps and those that were somewhat more welcoming, somewhat as an<br>
interim, a new policy of pretty much "just no" (except for fancy<br>
autocomplete by those with clue) was proposed and adopted.  Basic issues<br>
were limited human maintainer bandwidth, humans not being happy about<br>
interacting with machines, and code that looks very plausible but isn't<br>
quite right, in a way that's very hard to identify.<br>
<br>
qgis policy:<br>
<br>
  <a href="https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md</a><br>
<br>
revised gdal policy, after a brief experiment with a policy like qgis's:<br>
<br>
  <a href="https://gdal.org/en/stable/community/ai_tool_policy.html" rel="noreferrer" target="_blank">https://gdal.org/en/stable/community/ai_tool_policy.html</a><br>
<br>
<br>
My own experience was in seeing hamlib (not geo) get a vibe-coded PR<br>
while talking about policy, and I and several others reviewed it.  Both<br>
code and PR text were very wordy, in a way that wasn't helpful, and in<br>
the end we decided the PR was off base.  But it took a lot of time, it<br>
was hard to determine if it was right or not, and a (trained software<br>
engineer) human would have made much smaller changes and explained them<br>
far more concisely.  This experiment left me thinking that it wasn't ok<br>
to ask humans to review, read, or otherwise deal with LLM output.<br>
<br>
Thus, I favor the gdal approach.  I suspect that after a few vibe-coded<br>
PRs, those reviewing them will prefer that too.<br>
<br>
Regardless of how the consensus ends up, postgis should state the rules<br>
in CONTRIBUTING, and IMHO the rules should include up-front disclosure<br>
of *any* LLM use in making a contribution, beyond the human contributor<br>
gaining understanding.<br>
</blockquote></div>