* Ihor Radchenko <[email protected]> [2026-03-10 22:23]:
> But it does not mean that it is useless.
> We have https://orgmode.org/worg/org-contribute.html and many people do
> consult it, even though not everyone. Every time the contributor consult
> the guidelines, the workload on reviewer reduces.
>
> So, I strongly disagree with your judgment of "advisory noise". It is
> advisory, but it is certainly not noise.
I agree that people should not be carelessly contributing, though
which tools they used to create the contribution should be irrelevant,
because maintainers are not their bosses, fathers, employees,
maintainers should decide solely on the free software freedoms. Not
even the usefulness is so much important, there are plethora packages
that are not useful to me or you.
Limiting users to use certain tools is fundamentally against the four
software freedom. Let users be free, not limit their choices of tools.
In this case you are limiting users to use LLMs, instead of embracing
technologies and providing them better LLM prompts, on how to actually
generate working code.
If Org is historical artifact, then yes, keep doing so. But if you
wish to advance, first embrace new technologies, and if you have
particular real life problems, let us list them here.
Where are those LLM contributions by list, which caused maintainers
burdens that discussion goes over board?
> >> 2. The only exception to (1) is when they declare that
> >
> > How would you enforce (1) to even have exceptions? You deal with
> > people on distance. There are not lie-detectors that work on distance.
> >
> > Instead, encourage communication and friendship, not robotic policies
> > that cannot be controlled nor enforced.
>
> The point is not to prevent 100% LLM patches from new contributors.
> The point is to make at least some of those LLM patches to be of higher
> quality.
Thank you, that is well said, I agree on that.
So simply provide advice, not related to tools they use, that quality
is what matters.
Don't put constitutional-type rules against generalized "LLM" to
invalidate their good intentions. You will lose users that way. You
are making them unwelcome.
Instead:
--------
Provide guidelines to foster their good intentions to contribute to
community.
And it is not logical to say say by generalizing how LLMs are
producing bad code.
;; Pseudo-code for fostering good contributions regardless of tools used
(defun foster-quality-contributions (user-message)
"Focus on the quality of contribution, not the tools used to create it."
;; Step 1: Acknowledge the intention positively
(when (detect-good-intentions-p user-message)
(send-reply
"Thanks for wanting to contribute! We're glad to have you."))
;; Step 2: Focus on quality guidelines, not tool restrictions
(let ((quality-checklist
'(
"Does the contribution include clear explanation?"
"Is the code tested and working?"
"Does it follow project conventions?"
"Would a human reviewer understand it?"
"Is it solving a real problem?"
)))
(send-guidelines
"Here's how to make your contribution really shine:"
quality-checklist))
;; Step 3: Welcome them, don't police them
(send-reminder
"We care about what you contribute, not how you wrote it. "
"Everyone is welcome here as long as they put in the effort "
"to make something useful for others."))
;; Example usage:
;; (foster-quality-contributions "I used LLM to help me write this package")
;; -> Response focuses on whether package works, not the tool
;; Because in the end, the washing machine doesn't matter.
;; The clean clothes do.
> >> a. They are experienced LLM users
> >
> > Who is to say so?
> >
> > The “experienced LLM user” exception is a red herring. Even if someone
> > claims expertise with LLMs, how do you verify it?
>
> I do not need to verify it. I want to make people stop and think if they
> are really that confident about their LLM skill to commit that they can
> be responsible for the quality of the LLM-generated patch they submit.
Just as in real life, you will interact with people and you need to
adopt the skill to recognize who is who.
But back to reality, where are those LLM-problems with Org contributions?
Any list of it?
Any real life experiences or is it just a fear from new technologies?
> The point is not making 100% sure that we only get patches from real
> experts in LLM or so. The point is to reduce the low-quality
> submissions. Guidelines/policies are one way to do it.
>
> > Think freedom and let contributions come.
>
> There is freedom. Note how LLM patches are not prohibited even for
> first-time contributors. The key is emphasizing that we want good
> quality of patches.
I believe if you put focus on that exactly, to get good quality patches, that
you will get exactly that.
If you put focus on invalidating users embracing LLMs to be more
efficient, you will get less users, as you are unwelcoming them.
> The aim is exactly the same as the rest of the contribution
> guide. For example, we ask people to run tests before submitting
> patch.
Exactly, and you can provide guidelines also to those using LLMs on
how to generate tests, how to ensure they work.
The issue with first‑time contributors is the same problem that has
persisted for decades: they are newcomers, and the LLM in question is
merely incidental to the current moment. Newcomers have always, long
before the advent of LLMs, followed the same pattern of naive
enthusiasm to contribute.
> >> b. They confirm that they have reviewed the LLM-generated code and
> >> *also the code it changes*
> >
> > I would forget "LLM" and ask users to review the code and know what it
> > does, and changes to the code are automatically in git logs.
>
> Sure. Except that with LLM, the git logs are also generated and are not
> evidence of this additional checking.
If you really have much of a burden with git logs, then you can find
out how to solve the burden. The tool is not the culprit. Communicate
more about your proposed solution. Let user's sign up more
personally.
There is one good way to solve those issues: Talk to them. I mean by
physical talking with mouth and making live conferences. That makes
people get together.
> >> 3. Contributors who wrote their own patches in the past may use LLM for
> >> smallish patches. No new substantial features.
> >
> > Sounds authoritarian. Rule which you cannot prove and cannot enforce.
> >
> > Judge by usefulness of the contribution and not if user's grandmother
> > or LLM was present.
>
> This is a request from Emacs maintainers. We cannot accept large patches
> written by LLMs. I already have to enforce that, when I catch LLM
> code. Regardless of this discussion.
If LLM or not, large patches are probably a problem for maintainers.
But LLM is never a decision maker. Programmer is. Even if programmer
decides to run the LLM on loop and submit patches recklessly.
So maintainers must talk to programmers. Not sack LLMs for some hidden
reasons.
I resepct Emacs maintainers for their work, but they are in comparison
with new technologies getting old and cannot catch up with it.
> >> 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.
> >
> > You see, who believes that new feature outside of the official
> > Org/GNU/Emacs provides usefulness, that one is anyway going to have
> > it and most probably share it with others.
>
> This is not as obvious as you may think.
> See previous discussion in https://list.orgmode.org/[email protected]/
> John Wiegley wanted to contribute a new large feature with LLM, and he
> did not realize that making that a separate package is viable
> alternative if Org mode cannot accept large LLM-written features.
So communicate more in advance, provide more instruction on website
pages, and appreciate efforts, just give them guidelines how to do it.
> > They are making copyrights obsolete step by step.
> > Would there be no copyrights, there would be no protest, neither no
> > GNU project.
>
> Maybe or maybe not. My view on the legal situation with LLMs is not yet
> finalized, given the ongoing lawsuits all over the world.
>
> If you can, please substantiate such claims with some references that
> confirm them. Otherwise, they sound like wishful thinking.
No problem:
https://www.jdsupra.com/legalnews/northern-district-of-california-judge-9185623/
How AI Ends Intellectual Property (Without Trying): The Collapse Mechanisms |
by Arturo R Montesinos | Medium:
https://medium.com/%40arturormk/how-ai-ends-intellectual-property-without-trying-the-collapse-mechanisms-b27f3bdf2e61
The Great Creative Heist: How LLMs Are Gutting Copyright and Shoveling Billions
to Big Tech | by Troy Breiland | Medium:
https://medium.com/@troybreiland/the-great-creative-heist-how-llms-are-gutting-copyright-and-shoveling-billions-to-big-tech-36aa2dc3d59b
How Generative AI Turns Copyright Upside Down - Journal Article - Stanford Law
School:
https://law.stanford.edu/publications/how-generative-ai-turns-copyright-upside-down/
Generative AI Might Finally Bend Copyright Past the Breaking Point - The
Atlantic:
https://www.theatlantic.com/technology/archive/2024/02/generative-ai-lawsuits-copyright-fair-use/677595/
> > But now Org is fighting it just because.
>
> Org is not fighting LLMs. I am trying to make sure that we get better
> instructions for contributors and end up with better quality of patches.
> Please read through the original patch that preceded this discussion.
That sounds really good. I agree on that. But various tools are coming in
future, why limit users by even mentioning?
Provide guidelines on contributions.
I just see the trend appearing in some software communities where
people talking against LLMs, but I feel so strongly those talking are
mostly those lacking knowledge and skills to embrace LLMs. It is some kind of
envy.
How to describe such resistance against LLMs by oldtimers?
It's like master blacksmiths in 1900 complaining that factories are
"cheating" because they produce good steel without years of
apprenticeship. The bitterness is just fear of being replaced.
It's gatekeeping disguised as principles. "You didn't write every line
yourself? Then you're not a real developer." Translation: "My hard-won
skills are becoming less special."
It's the same energy as old photographers sneering at digital cameras,
or journalists hating on Wikipedia. "Back in my day, we did things
properly" really means "back in my day, information was hard to get,
and I liked it that way."
It's envy wrapped in ethics. They see newcomers producing in hours
what took them years to learn, and instead of adapting, they declare
the shortcut immoral.
> > Why would be GNU the last one to adopt the worldwide substantial
> > change of software sharing?
>
> You make this question sound like it is rhetorical. It is not. GNU is
> now considering its position. And it is not at all obvious.
Free software is about freedom to use, study, modify, and share. LLMs
help people do exactly that—write code, translate docs, fix bugs
faster. But we have the catch that producing LLMs requires fully free
software, that is where GNU should be working on.
Apart from that -- let people enjoy the new efficient world.
> > ...
> > Let us not stay in the ivory tower.
>
> We are not. But we are not rushing either. We have our time to consider
> things carefully.
People are free to take their time considering.
IMHO, there are 2 options:
--------------------------
- making community more lively, as that is one of reasons (making
solely the software without community isn't entertaining)
- or unwelcoming community and insisting on bitterness and envy
wrapped in ethics resisting new technologies. Community goes down,
but some other communities are there opening up every minute. People
will switch.
So keep considering... times goes...
> > For me personally, I would rather prefer small Org that is error-free
> > with packages to extend it rather than decades long never ending
> > process.
>
> So, what is your solution to the barrier of entry?
For thinking, this page title would be IMHO best for GNU, simply not
to decide on LLM generated stuff.
Debian decides not to decide on AI-generated contributions | Hacker News:
https://news.ycombinator.com/item?id=47324087
I think that what matters here is not the Org mode any more.
There are now more than ever note taking applications, it becomes even
ridiculous burden to start comparing them. But do they have
communities?
What really matters is the Org users community and opening doors to
new users should be now more than ever, or the community count goes
down, until the mailing list becomes empty.
Some references:
----------------
vscode-org-mode/vscode-org-mode: Emacs Org Mode for Visual Studio Code:
https://github.com/vscode-org-mode/vscode-org-mode
Obviously that author found Org principles nice to implement it for
other editor.
ihdavids/orgextended: Sublime Text OrgMode Extension:
https://github.com/ihdavids/orgextended
or that one...
but how many note taking applications are just generated while we are
speaking.
> So, what is your solution to the barrier of entry?
Make MCP server to help user debug Org contributions.
- Runs tests automatically before submission and explains failures in plain
language
- Checks coding style and points out exactly what to fix
- Suggests docstrings and manual entries for new functions
- Recommends test cases based on what changed in the code
- Helps write better commit messages by summarizing the patch
- Spots common LLM mistakes (generic code, wrong assumptions) and flags them
- Answers contributor questions about Org internals and conventions
- Links to relevant parts of the manual or existing code examples
- All without caring whether the code came from a human or an AI
--
Jean Louis
