Jean Louis <[email protected]> writes: >> 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.
Yes, I was talking about Org mode mailing list here. I do not get another two questions. Could you elaborate? >> 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. See https://orgmode.org or CONTRIBUTE.org file in the repository. >> 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/ https://list.orgmode.org/orgmode/[email protected]/ https://list.orgmode.org/orgmode/[email protected]/ https://list.orgmode.org/orgmode/[email protected]/ https://list.orgmode.org/orgmode/CALjq+LZJ-28Bg_TQ3TsGO9-Ot-=dWtFzkKAuqh9vJy5ie=e...@mail.gmail.com/ (probable LLM assist) >> 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. 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. Moreover, the review time is not always faster compared to writing the code by the same reviewer. For many patches from first-time contributors, I would spend less time writing a given patch myself compared to the review process. That extra time on my side is only justified when the contributor ends up learning more and come back later, with more complex patch, where the review is faster than writing it myself. > 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. I'd argue that (2) is even more important. And LLM potentially hit on developing the community. Again, not always, but I can foresee how the impact can be negative, as I explained. >> 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, Are you commenting about other replies in this thread? >> 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. > By "users" or by "user"? User. The patch where this thread started is concerning. > - Modernize the contribution workflow by adopting a self-hosted > Forgejo/GitLab instance with pull requests What about sourcehut? Also, check out https://orgmode.org/worg/org-maintenance.html#orgf4a3964 > - Create clear, beginner-friendly documentation for the current email > workflow while it exists We have https://orgmode.org/worg/org-contribute.html Any concrete suggestions about how to improve it? > - Actively mentor new contributors without scolding or making > assumptions about their tooling That's what we do. But see the above concern. > - 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? > - 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 > - Plan for maintainer succession with an eye toward inevitable > workflow modernization Could you elaborate what you mean here? Workflow and maintainer succession seem orthogonal. -- 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>
