I think there are some other good points in this thread around the implications for learning, engagement, and other non-technical aspects that should be thought through.
Having said that, the list looks generally reasonable to me. I would also lean toward making it explicit that the *person* contributing the code owns the contribution (perhaps not legally, pending the upstream discussions), but in terms of responsibility. The contributor of a patch is responsible for the code regardless of how it was generated: 100% manually, with the help of some yasnippet templates, or via an LLM. For now I would 100% push back against any contribution in which a human has not reviewed and submitted the patch(es). I also think that before you open up this policy, we need to discuss how we handle people (or bots) who ignore, misunderstand, or who are not aware of the guidelines you've written. Cheers, Derek On Sat, Mar 7, 2026 at 6:57 AM Ihor Radchenko <[email protected]> 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 > 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. > > -- > Ihor Radchenko // yantar92, > Org mode maintainer, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> > > -- +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+
