On Saturday, 7 March 2026 13:56:48 UTC Ihor Radchenko wrote: > jman <[email protected]> writes: > > Ihor Radchenko <[email protected]> writes: > >> Also, I started this thread simply because LLMs are starting to affect > >> the Org development. I'd prefer to discuss the rules we will eventually > >> formulate on this list rather than elsewhere. This way, the records will > >> be preserved. > > > > Looking at my (and other projects) experience I think also orgmode is > > going in the direction of a "no-AI slop/spam" policy that covers not only > > copyright concerns (which are still cloudy and having the FSF in the loop > > makes the process longer). > > I'm leaning towards more receptive attitude. > Preliminary ideas are the following: > > 1. First-time contributors should be discouraged to use LLM
I completely understand the problem of having to sift through large amounts of poor code that arrive frequently. But how can you tell whether the code was generated by an LLM? The problem with LLMs is that poor code can easily resemble good code, which makes triage more difficult. Again: how can you tell if the code is from an LLM and, if so, to what extent? It's a complicated question to enforce in practice. > 2. The only exception to (1) is when they declare that > a. They are experienced LLM users > b. They confirm that they have reviewed the LLM-generated code and > *also the code it changes* > 3. Contributors who wrote their own patches in the past may use LLM for > smallish patches. No new substantial features. > 4. Regular contributors may be trusted to use LLM assist for new > features. They are probably experienced enough to review the > generated code and make sure that it is reasonable. > > However, large new contributions made by LLM (as in (4)) cannot be yet > accepted. We need to wait for GNU to provide official guidance (which > they are working on). For users who absolutely want to use LLM and > believe that the new feature provides a lot of value, we will suggest > implementing those new features as a separate package. We may accept > optional support for that separate package into the core. > > Small LLM contributions that are <15LOC (the same criteria as for > patches from people without copyright assignment) are allowed, but > considering all the above. > > > You folks are lucky :-) because the barrier of entry for contribution here > > is higher than on GitHub (patch workflow and everything) and this > > protects the project. But you know how dire the situation is out there. > > > > Let me know if I can help, I (unfortunately) had to dive into this topic > > way more than I wished. > Let me know if any of the above smells disaster.
