Hi everyone, I think we should seriously consider distinguishing between two types of contributors:
1. Transactional Contributors: People who simply want to fix a specific issue they are facing. 2. Community Contributors: People who genuinely want to be part of the community, help make product decisions, engage with other members, learn, and share knowledge. For the first group, I see great potential in leveraging AI to process and validate contributions with minimal human overhead. With thousands of issues that users want to solve, AI tools now make it feasible to generate reliable fixes. Everyone benefits as long as we establish automated workflows to review, test, and accept these contributions without consuming valuable maintainer time. The more we can automate this layer, the stronger the project's foundation will be. For the second group, we need a clear path that allows these contributors to move past initial automated gates and connect directly with maintainers. Once we offload the transactional review workload, we can dedicate almost 100% of our human attention to meaningful, human-to-human community interactions. To achieve this, our discussions should shift away from line-by-line code reviews. AI agents and automated harnesses are already better suited for checking code invariants, conventions, and implementation details. Instead, maintainers should focus on higher-level priorities: assessing intention, discussing long-term vision, defining project boundaries, and designing the automated guardrails. I would love to hear your thoughts and discuss ideas on how we can automate transactional fixes so we can focus our time on the broader "why" behind our project. I think the difficulty lies mainly in separating contributions of type 1 from 2. And maybe we should think how to make it more "obvious" which is which. Best regards, Jarek On Sun, Sep 27, 2026 at 9:07 PM Justin Pakzad <[email protected]> wrote: > > Hi all, > > Just wanted to chime in with an idea related to the topic of human > summaries. The proposal above is mainly focused on PR descriptions but > I feel we should apply a similar concept to PR reviews and general > communication, encouraging users to write their own reviews and > responses. If you can't explain it in your own words, should you still > be involving yourself? Doesn't mean you can't use AI but at least some > human interaction. I think most people are also more receptive when > they see there is actual human interaction (as Jarek mentioned on > Slack), rather than receiving a response from an agent. I know there > is already a maintainer PR triage process in place which typically > involves an automated first pass so I'm not implying maintainers > should have to adhere to this (that would be counterproductive). > > There are obviously counter arguments to this. If someone is willing > to spend their own tokens and it actually helps move things along then > is it actually a problem? Some people also express themselves better > in their native tongue and might use AI to help translate to english. > Those are just a few that came to my mind. > > If this is something the community feels is important to encourage, > then I think a good first step could be to extend some of the language > in the contributing docs. In regards to reviews, the docs mainly just > encourage reviewing but don't mention anything about AI. Same can be > said for the how to communicate docs. Curious to hear everyone's > thoughts. > > - Justin P > > On Thu, Sep 24, 2026 at 11:02 AM Jarek Potiuk <[email protected]> wrote: > > > > > But mostly I was assuming that the agents would mostly follow the skill > > and existing docs, so we don’t _need_ to do anything else for humans to > > fill it in, as by default they will do that anyway. > > Actually, I think this change is the first time we are adding that > > requirement. We never asked agents to stop and "expect" the PR description > > to be written by hand. We wrote that we expect humans to understand their > > changes and be responsible for it. But we never expected **agents** to stop > > and ask the operating human to write the description by hand. > > > > Do you think it was written somewhere Ash? (I could not find it). And maybe > > its' the right time to **quickly** refactor our agents.md and others > > without doing the complete work that our intern is doing. One problem with > > those instructions for agents is that they don't read the full "long" > > context initially and might "miss" some instructions. > > I am recently doing optimizations in Magpie - and making sure that all the > > SKILLS and tools are written in the way that they follow some budgets, and > > limitations - I can definitely use the magpie skills to optimize our > > agentic instructions. So Aiurf > > > > Jl > > > > > > > > On Thu, Sep 24, 2026 at 4:53 PM Ash Berlin-Taylor <[email protected]> wrote: > > > > > Yes, the html comment would fork fine too. > > > > > > But mostly I was assuming that the agents would mostly follow the skill > > > and existing docs, so we don’t _need_ to do anything else for humans to > > > fill it in, as by default they will do that anyway. > > > > > > > On 24 Sep 2026, at 15:44, Shahar Epstein <[email protected]> wrote: > > > > > > > > Ash - I understand your approach, and not against the formulation that > > > you > > > > suggested (without headers + changing "Click here" to "AI Summary"). > > > > However, I think that it will be easier for contributors to comprehend > > > that > > > > they should write the description in their own words if there's an > > > explicit > > > > instruction for doing that. If you're against headers, it could also be > > > in > > > > the form of an HTML comment like we already do in other areas (i.e., > > > > <!-- > > > > YOU MUST WRITE THIS SECTION WITHOUT LLM -->). > > > > Personally, I think that headers will have a better effect as they are > > > more > > > > visible (for both author and reviewers altogether). > > > > > > > > > > > > > > > > Shahar > > > > > > > > On Thu, Sep 24, 2026 at 5:34 PM Jarek Potiuk <[email protected]> wrote: > > > > > > > >> Hello everyone, > > > >> > > > >> Following the objection in the [LAZY CONSENSUS] thread, I am turning > > > >> this into a discussion. The change (#73660) has already been reverted > > > >> in #73669 (thanks Ash) - and apologies for merging it before the lazy > > > >> consensus ended; I thought it was uncontroversial, which it clearly > > > >> is not. > > > >> > > > >> The original proposal, for PR descriptions drafted by AI agents: > > > >> > > > >> * The description starts with a short "Human Summary" - a few > > > >> sentences typed by the human author, in their own words: why the > > > >> change is needed, key decisions, caveats. > > > >> * The agent-written description stays below it, in an "AI Summary" > > > >> section folded by default. > > > >> * Agents are instructed to ask the author for the Human Summary and > > > >> paste it verbatim - never to write, suggest or paraphrase it. > > > >> > > > >> Ash's objection, as I understand it: the PR description should already > > > >> be written for humans, and it is how the author engages with the > > > >> community - so an explicitly labelled "Human Summary" reverses the > > > >> priority. His counter-proposal is to drop both the "Human Summary" > > > >> and "AI Summary" headers and put the agent text in a folded > > > >> <details><summary>AI Summary</summary> block. > > > >> > > > >> I see it the other way round. Following the ASF Generative Tooling > > > >> guidance, we already require every such PR to state that it was > > > >> generated with AI - the reader knows up front that an agent was > > > >> involved. Given that, an explicit "Human Summary" is exactly the > > > >> signal that matters: it shows that the human was driving the change, > > > >> and that they understand it well enough to summarize - in their own > > > >> words - what the PR does and why. Without the label, the reader of an > > > >> AI-disclosed PR has no way to tell which part the author actually > > > >> wrote. This is the "centaur" - human in control - not the "reverse > > > >> centaur" or "meat proxy" [1]. > > > >> > > > >> Looking at it again, the two proposals are closer than it seems: both > > > >> put the author's own words on top and fold the agent's text below. > > > >> The actual differences are: > > > >> > > > >> 1. Should the human-written part be explicitly labelled > > > >> ("Human Summary") so it is distinguishable in an AI-disclosed PR, > > > >> or just be the unlabelled top of the description? > > > >> 2. Should the folded agent text be marked "AI Summary" (Ash suggests > > > >> the <details> summary label - that part we seem to agree on)? > > > >> 3. Should agents be required to ask for the human part and refuse to > > > >> draft it themselves - or should that be left to the author? > > > >> > > > >> Just to remind - this is **only** for PRs that are agenically > > > >> generated. > > > >> If someone creates their PRs manually, without the AI agent, none of > > > >> this applies. > > > >> > > > >> The template for PRs opened via GH UI is not supposed to have either > > > >> section. > > > >> > > > >> I'd love to hear what others think - especially those who review a lot > > > >> of agent-assisted PRs, and Shahar, who has been using this format > > > >> already. > > > >> > > > >> [1] > > > >> > > > https://doctorow.medium.com/https-pluralistic-net-2025-09-11-vulgar-thatcherism-there-is-an-alternative-f1428b42a8fd > > > >> > > > >> J. > > > >> > > > >> --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: [email protected] > > > >> For additional commands, e-mail: [email protected] > > > >> > > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
