> > I like the AI policy GISP - do we need a similar one for GeoTools? Also do > we need to add ai.md or claude.md etc files to the repository? >
Personally I would like to have the policy adopted by all 3 projects. About adding an ai.md sure, we could have a well crafted one that avoids most of the AI slop at the source. Looks like placing an AGENTS.md file in the root of the project would have it picked by major code assistants. I was also thinking of adding an automated "AI slop detector" (fight fire with fire approach) but I'm a bit at a loss regarding which tool to use, copilot seems to have gone "pay per use" in repositories, ai slop detectors <https://github.com/topics/ai-slop-detection> look weak (anyone know of a good one?) and then there is CodeRabbit <https://www.coderabbit.ai/oss>, free reviewer AI for open source projects that can use, but I have no experience with it, I can't tell if it's any good or not. We might want to give it a spin for a short amount of time (the AI policy is not about disallowing AI usage, it's about using it properly). I see the tool is configurable <https://docs.coderabbit.ai/getting-started/yaml-configuration>, we can try it out an intial configuration and fine tune it as we go. > What direction will Jody's PR for the propertyDescriptors go? are we > enforcing it or removing any reference to them in the docs? > I'm confused about it to be honest... the javadocs say nothing about it, one has to stumble into PropertyAccessor directly, the filter function tutorial does not mention it, the filter documentation has two small references that are easy to overlook. I'm feeling attacked for having written a "broken function" in GeometryFunction, and I'm also being asked to fix all the broken functions in a follow up PR. Given that we talking about usage of AI, I asked Claude Code about this to get a third party opinion (notice, my CLAUDE.md is set up to be adversarial to my comments, rather than following what I say, it's useless in its default behavior). Here is the answer I'm getting (please excuse the succing english, I use caveman and I've robustly tuned Claude to avoid long winded explanations): *> What are the chances an experience developer would notice the need to use property accessors while writing a new function, and what are the chances a downstream user would notice? ● Near zero, both. Developer writing new function: ~0%. Path they'd follow: tutorial/function.rst (silent), Function/Expression javadoc (silent, Feature-centric wording actively misleads toward "just handle Feature"), existing functions to copy pattern from (GeometryFunction itself broken, so copying it propagates bug). Only route to discovery: stumble on library/main/filter.rst, a doc for filter users not function authors, unlikely reading material when writing a function, then follow a dead link to a guide that doesn't exist. You (20yr veteran) didn't hit it. That's the data point. Downstream user hitting the bug: ~0%, but for different reason — silent failure. evaluate() returns null instead of throwing. Reads as "no geometry" / "property absent," not "function broken." No exception, no log, no signal. User has to already suspect PropertyAccessor semantics exist and independently think to test the function against a Bean/Map, compare against Feature behavior, notice divergence. Realistically only caught by someone already deep in filter internals, i.e. someone like you, and even you didn't notice authoring it. Net: bug is invisible at write-time and invisible at use-time. Structural doc failure, not a one-off typo.✻ Cogitated for 9s> I wrote GeometryFunction as a core developer and I did not notice. Should it have been evident to me? ● No. Nothing in the path you'd have followed says it. You're core dev, know the codebase deeply — but knowing PropertyAccessor SPI exists somewhere in gt-main doesn't mean you'd think to reach for it while writing a Function, because nothing ties the two concepts together anywhere: not Function javadoc, not Expression javadoc, not the function tutorial, not even PropertyAccessor/PropertyAccessors javadoc pointing back the other way ("Function implementations should use this instead of assuming Feature"). Docs and code both silent both directions. Also: existing convention. Other functions in org.geotools.filter.function likely follow same Feature-first pattern Not a personal miss — a repo-wide convention gap that never got flagged in code review either, meaning reviewers didn't know either. So no — not evident, not because you missed something documented, but because nothing document-side or code-side exists to notice. That's the actual finding here: this isn't "Andrea didn't read the docs," it's "the docs and API contract never captured this invariant in the first place."* I am happy with enforcing it on the main branch, if anyone wants to put the effort to do that, but we'll need to point it out in upgrade notes, people implementing Function might have created downstream functions that assume Feature in good faith (I did too in GeoTools, you as well, and Jody too). Cheers Andrea
_______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
