lstahlman
> Mirrored from upstream: https://github.com/opencv/opencv/issues/28335 > Original author: @s-trinh · created 2025-12-30T05:28:31Z > Upstream labels: `pr: Discussion Required` > Selection: mirrored by mirror-issues.py --- With the generalization of LLM generated code, some new policy about contributed code should be considered (or at least discussed somehow/somewhere) in my opinion. This **extreme** example (seen from social networks) of LLM generated code from a contributor was, I would say, the "trigger": - https://github.com/ocaml/ocaml/pull/14369 Another discussion about AI may feel too much nowadays, but since I have seen some attempts to use Github Copilot in OpenCV repo to assist the reviewing process, this seems to fit here. Otherwise just close this discussion. --- After taking too much time to "think", the policy to ensure for contributions is actually quite trivial: - **the contributor must know what his code is doing** (in addition to the usual rules such as license (a whole topic IMO with LLM and licensed code from training datasets), test, etc.). In contrary, enforcing this rule is impossible. See the "Pull Request Readiness Checklist" where people will not read the PR template and will just copy/paste whatever the LLM outputs. It is entirely based on the honesty of the contributor. Otherwise too much time is spent to know if we are communicating directly to the code author or if it is just a relay to a "smart parrot". --- To conclude, I am linking here a guidelines proposal from another repo where all the ideas are already nicely (and better) summarized / you can even just skip all the above and just read the following: - https://github.com/ocaml/ocaml/pull/14052 Unfortunately, these kind of guidelines are useless since nobody will read it. This makes me quite pessimistic. --- ### _Update._ Another, linked, topic is the pull request description in my opinion. Similarly: - **the contributor must ensure that what is written in the PR description matches with the code,** - **and similarly, is fully responsible to what is written in the PR description and in the code** With LLM "era", I have never seen so much detailed PR description: 1. this is not school, this is not a student / professor relationship, there is no grading, no need to flood the communication to try to convince the interlocutor that the PR should be merged 2. hopefully (in an ideal world), both the contributor and the repo maintainers **share the same interest** ; or to put it directly, there is no course to whom has opened the most PRs, has commited the largest amount of lines of code, etc. just for self-promotion, to have a portfolio for hiring (In an ideal world.)