* Ihor Radchenko <[email protected]> [2026-03-14 17:00]: > > I just believe that contributors to Org mode are not reckless as given > > in those generalized statements. > > There are sometimes lower-quality contributions, but not often. > But I suspect that part of the reason is the barrier of entry > (email+patch workflow).
Thanks for bringing up reality. > LLMs objectively lower the barrier of entry. More so in more > mainstream workflows like in web pull requests (agent APIs and MCP > servers make the barriers even lower there), but also for patch > workflows. Are we talking Org mode here? AS you said there are sometimes lower quality contributions, but now you say about LLM lowering barrier of entry. But who complained in Org mode communit that LLM lowering barrier of entry? Is there patch you can reference to? As I think only in the context of Org mode mailing list and not in broader one. > So, I do anticipate less experienced contributors to submit patches to > Org as a result of LLM adoption. Sounds positive. > More contributions are generally a good thing. However, they are only > good when the patch quality is good. Or, alternatively (that's > important!), when the less experienced contributors are ready to learn, > and later come back with more, better-quality patches. Where is the instruction on how to submit those patches? I cannot find by searching "contribute" in the info manual. Let me see it. > LLMs create problems here. In *some* (not all, mind you) cases, users do > not need to learn anything and simply hand over a task to LLMs, still > getting something that is working (or seem to be working). Users or user? How many users did that in the Org mode coding environment? Send me references. It must be a public reference, not so? > Without LLMs, I could simply ask to fix things in the patch, and the > user will have to learn by practice. With LLMs, my instructions risk > simply being fed to LLM - that will get the patch improved, but > contributor's understanding of Org code will not improve much. Right. When feedback gets fed directly into an LLM, the contributor misses the cognitive work that builds mental models of Org's internals. The struggle to understand why we use org-element instead of regex, or why a particular edge case matters, is where real learning happens. But contributing to Org mode isn't about contributing to learning of the contributor. The purpose is to improve Org mode for everyone, and especially for those people who don't know how it runs and what is it's code. If person contributed anything, probability is so high that person knows what he contributed, I would not go into discussion of that. Contributor sends contribution. Managers or maintainer they decide if good or not good, and can discus on it. It carries learning process in itself, let's not be judgy on information we cannot even asses, we cannot know how much that person really learned about the code unless you see his code finally, or start talking. But we are not here on mailing list to measure how much who learned, but to get mayb better Org mode. > In order for such LLM contributions to be useful (not just for the patch > in question, but also for building the contributor community), we need > people to *build understanding* of the code. And that requires learning > effort. But how to encourage such learning? Sorry, me I just see discouraging. Encouraging is something else. The attitudes (anti-this, anti-that), scolding tendencies, > The above is not a theoretical question. This discussion was triggered > by LLM-generated patch. And we had a couple LLM-assisted patches in the > past as well. By the "patch" or by "patches"? By "users" or by "user"? > 5. Do not check, treat all the patches equally. That's roughly what we > do now (except that we are prohibited from accepting patches that are > declared to be written by LLMs as instructed by Emacs upstream). > But, as I wrote above, this approach may hurt building the *regular* > contributor community - people familiar with the project who can > become future maintainers. I find the last option half-best. You should treat all patches equally. People may use or not use LLMs, why waste your time on thinking about it. Like now. Why waste time on judging remote sessions, remote users, scolding them, surprising them with your opinion which may appear to them so much contrary to what they have learned. They are also new generations, not old. They will not know what you know now. They move with new technologies. The most probable prediction: when the current generation of maintainers who built their workflows around email dies off, the GNU project will face an unavoidable choice—either adapt to modern contribution workflows (likely GitLab or similar self-hosted Forgejo/GitLab instances) or watch contribution rates decline sharply as the pool of developers willing to learn email+patch shrinks to near zero. The transition won't happen because anyone wants to change, but because the alternative is irrelevance. New maintainers, raised on GitHub in university and early careers, won't enforce workflows they themselves find arcane. The project will slowly modernize or slowly die. Remedy situation: - Treat all patches equally regardless of whether LLMs were used, judging only on technical merit - Modernize the contribution workflow by adopting a self-hosted Forgejo/GitLab instance with pull requests - Create clear, beginner-friendly documentation for the current email workflow while it exists - Actively mentor new contributors without scolding or making assumptions about their tooling - Recognize that younger developers (new generations) have different learned workflows and meet them where they are - Focus on code quality and project improvement rather than policing how contributions were generated - Plan for maintainer succession with an eye toward inevitable workflow modernization -- Jean Louis
