Jean Louis <[email protected]> writes: >> Preliminary ideas are the following: >> >> 1. First-time contributors should be discouraged to use LLM > > Risk: “Discouraged” is non-binding. Without enforcement mechanisms, it > becomes advisory noise.
It is indeed an advisory. And yes, we cannot force people to follow it just as we cannot force people to follow the contribution guidelines beforehand. 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. >> 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. >> 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. 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. The aim is exactly the same as the rest of the contribution guide. For example, we ask people to run tests before submitting patch. Not everyone does, but those who do can catch issues early, without having me or another reviewer run into test failures and ask to fix them anyway. >> 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. >> 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. >> 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. > > You will just create more barriers, instead of welcoming users. Is this comment about (4) or is it about something else? >> 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). > > GNU was fighting for user's freedom in software sharing, and now is > time to recognize that there is more freedom due to existence of LLMs, > more than ever before. > > The real question isn’t whether LLMs are “allowed” by some external > authority—it’s whether they help or hinder the project’s goals. If > LLMs can assist in writing better code, documentation, or patches, why > not embrace them? If they can’t, the problem isn’t the tool—it’s the > user’s ability to evaluate it. This is not up to me. The Org mode code eventually lands in Emacs, and Emacs maintainers decided that they first want GNU to carefully consider implications of LLM code before allowing such contributions. If you want to influence GNU decision-making, gnu-prog-discuss is an appropriate place. >> 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. > 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. > 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. > 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. > ... > 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. >> Small LLM contributions that are <15LOC (the same criteria as for >> patches from people without copyright assignment) are allowed, but >> considering all the above. > > How would you know it? RMS approved this approach. Eli approved this approach. There were no major arguments against the idea from other GNU hackers either. >> > 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. > > You’re right: the patch workflow and Org’s traditional contribution > model feels like a fortress. But fortresses don’t protect > projects—they bury them. The "high barrier" you’re proud of is the > same barrier that’s pushing contributors away while competitors (with > lower friction, LLM assistance, and global reach) swallow the market. > > Look at the number of MCP servers here: > https://www.modelscope.cn/mcp > > Imagine if those websites would be giving users hard time to > contribute as in this environment? > > People are reading your words, and majority will remain silent. Can > you think how does your self-imposed rule reflect on potential > contributors? > > 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? -- 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>
