* Ihor Radchenko <[email protected]> [2026-03-14 18:25]: > See https://orgmode.org or CONTRIBUTE.org file in the repository.
Great Ihor, I can see here: Contributing to Org: https://orgmode.org/worg/org-contribute.html > You do not need to be proficient in programming to contribute to Org > mode. You are even allowed to make mistakes ;) Just drop us an email > (no mailing list subscription required) with your idea (or asking > for an idea) and we will guide you along. That is very inclusive statement. Very welcoming, warm and nice. Though the mailing list isn't so in my opinion. You are asking for quality code on the mailing list, several participants mentioned it, yet the public statement says contributor doesn't need to be proficient in programming. I find the public statement so good. Yet, on this link, which I was searching in the firt place: https://orgmode.org/worg/org-contribute.html#patches just I don't find it clarified enough to people who are not proficient in programming on how to do that. It is contradictory there. However, the general link https://orgmode.org/worg/org-contribute.html points out to many ways of contributing, like submiting bug reports, participating in the mailing list, contacting maintainers, so I must say, according to public representation it is so friendly and nice. > https://orgmode.org/worg/org-contribute.html#patches No, the text is not clear to people who are not proficient in programming. It assumes prior knowledge of: - Git terminology: Concepts like "patch," "branch," and "commit" are used without explanation. - Command-line usage: The instructions use shell syntax (`~$`) and specific commands (`git pull`, `git format-patch`) that require familiarity with the terminal. - Software development workflows: The process of contributing code via patches is treated as a known concept. For a complete beginner, this document would be overwhelming as it lacks: - Basic definitions of Git. - Guidance on installing or setting up Git. - Visual aids or alternative methods (like graphical interfaces). - Contact information for seeking help. It is best suited for developers who already understand how to use Git and the general process of free software contribution. > >> 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? > > https://list.orgmode.org/orgmode/caawxjfd2yx1yyeo8le8i30xb3ooz1f3uqlcrscfzewxufsu...@mail.gmail.com/ I see there: > Matthew Weymar <[email protected]> writes: > > OK. I haven't done this before, so please bear with me -- and redirection > > is welcome(!) > Thanks for the patch. Before I review it, could you please let me know > if you used LLM to write it? > -- > Ihor Radchenko // yantar92, Then I see: > From: Matthew Weymar <[email protected]> > Of course, I can -- and of course, I did! > Do you have a preference as to whether people do or do not use an LLM to > write a patch?... If so, I am curious as to why. > M and then you scold him like here: https://list.orgmode.org/orgmode/871pi3iasi.fsf@localhost/ So that behavior on public list isn't really well aligned to good behavior I am used to. And what is your critics? > Policy Restriction: Emacs maintainers are instructed not to accept > LLM-generated patches due to unclear GNU licensing policies. Why not say that on the page itself????? ---------------------------------------- https://orgmode.org/worg/org-contribute.html So you cannot be contradicting your own community. I don't know that guy, but I can see that Matthew Weymar was excited and helpful. Is how now still excited and helpful? If patch ignores "\n" as a standard, then point out to him. Teach. You can give him better LLM prompt. You can provide testing-script.el or teach people workflows to understand. That he "missed implicit learning" is your judgment. Obviously from the sole discussion we are all learning. On your page https://orgmode.org/worg/org-contribute.html there is no requirement that contributor should learn anything. Be welcoming, let people learn through the process, it is inevitable, we are all learning something new every day. Who is more learning than Org mode users?! It is so clear, no matter what, user is compelled to learn. Let it to the process, not judge people. Basically apart form "\n" there was no substantial issue declared in your answer here: https://list.orgmode.org/orgmode/871pi3iasi.fsf@localhost/ Conclusion: Willing and helpful newcomers are unwelcomed. --------------------------------------------------------- I know they are welcome in reality, but the way of declining is too technical, too complex, and giving wrong impressions. Instead of welcoming new member, guiding, his appetite get lost... > https://list.orgmode.org/orgmode/[email protected]/ On that one link, you basically unwelcome honest user. Did you use LLM? Yes. You are unwelcome. Honesty is punished? Anyway -- I see no significant issues. I would re-organize, and any patches, I would let people talk to me before anything, send me patch, I try it out, and we talk about LLM whatever. Don't let people get surprised, like how you do now, welcome and unwelcome workflow. > My point is that *this is not always the case*. > Not all the contributions are equally good. > > Please keep in mind that patches need to be reviewed. I agree, but if you find it difficult, make a better workflow. I have improved my workflows over 2025 significantly, I am 100 times faster by using LLMs running on the computer. It is indispensable. In general, don't let just contributors contribute LLM generated code, use the LLM to understand issues and work on it. Embrace it. Finally, by punishing people for being honest, you will get the reverse situation, people will not be honest, they will tell you they did not use LLMs to make the code. They did nothing wrong from their perspective. Enthusiastic and good people are unwelcomed for using LLM, they will say "WTF" and would run away. People read mailing list. GNU project has sparked free software, but can't keep up with new technologies. Maybe there is no money to pay for staff time and effort. It should be GNU in the first place creating fully free LLMs and replacing CUDA, and what else, but we are dwelling on Org patches. :-) > > 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. > > Getting better Org mode involves two things: > 1. Better code > 2. Healthy contributor community of people who know how things are > designed and how things work. You can't expect that. Is too high expectations. "You don't need to be proficient." -- keep the good statement in mind even on the mailing list. Let people contribute, welcome everything. Other communities around Org mode coming into existence, GNU Org losing members maybe? By implying you are calling people unhealthy. It isn't nice. > Healthy contributor community of people who know how things are > designed and how things work. So others who don't know how things are designed and how things work are unhealthy? That makes no sense. I believe in your ability to see these points I am laying out here. > >> 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"? > > Patches. So far those few patches are not even worth discussing this much. Either you got time or no. Ask other people to verify those patches for you, or learn yourself how to verify it by using opencode for example. Maybe using opencode for verification isn't forbidden? > > By "users" or by "user"? > > User. The patch where this thread started is concerning. Okay, there were few users, and I apprecate you have sent links to show me the issue at hand, but no real problem I found, what? Maybe "\n"? > We have https://orgmode.org/worg/org-contribute.html > Any concrete suggestions about how to improve it? I have many suggestions, it is not easy for those not proficient to get through it, I would make it more easier and clear and would ensure that each of those possibly linkable terms get linked. > > - Actively mentor new contributors without scolding or making > > assumptions about their tooling > > That's what we do. But see the above concern. I see that concern is overbloated for few submissions, and no real technical problem at hand. > > - Recognize that younger developers (new generations) have different > > learned workflows and meet them where they are > > That's fine. But we have a number of Org mode-specific workflows, > including testing, and documentation standards that need to be learned > as well. Are you saying that we need to switch everything to "industry > standard" so that people do not need to learn as much? Or is there a > specific boundary line on what should be learned and what should > not? I am saying that you as maintainer you could think how to streamline your workflows. I have pointed out in this email, I have taken effort to read, I am definitely interested that you get more time, not less and that people are happy. But cannot see how those workflows function on your side. I find it now cumbersome due to your explaining that it is not easy to review it all. Why not automate it? There are free software alternatives automating the review process. I have found within few seconds few of them. It is out there. > > - Focus on code quality and project improvement rather than policing > > how contributions were generated > > Sorry, but community guidelines is an actual industry standard. Absence > of the guidelines have been shown to hurt the project development. > See https://dl.acm.org/doi/10.1145/3106237.3106246 Link isn't readable to me. I am skipping it. In GNU there is bunch of absences of guidelines for that reason. Actually GNU is less strict then many other projects. As manager of a company I must have some policy to work with, customer calls, I must know what to tell him. I cannot be advertising one thing, then once customer comes, telling him, he needs to eat specific hamburger in specific restaurant, otherwise he is not welcome. First revise your own workflows. > > - Plan for maintainer succession with an eye toward inevitable > > workflow modernization > > Could you elaborate what you mean here? > Workflow and maintainer succession seem orthogonal. When a project relies heavily on: Manual review processes Tribal knowledge about "how we do things" Maintainer-specific scripts or workflows that aren't documented Implicit standards that everyone "just knows" ...then bringing in a new maintainer becomes exponentially harder. The new person has to absorb not just the codebase, but an entire set of manual processes that may only exist in the outgoing maintainer's head. -- Jean Louis
