OK, I was **really** surprised to see that people consider it "normal". I
hesitated quite a bit to do it, but yeah, it looks it is indeed "normal".
So, just to fight my own bias, following Ash's comment, I looked at the
data and based things on actual evidence (below).
Indeed it seems that maintainers who use agents have naturally started
doing more and more of it - it was just 2% in May, and now we have 12% (!)
in the first 9 days of October.
I fully agree now - no need to document it. It's just very natural
consequence of maintainers choosing to "apply fixups" rather than "post
comments" with their agents.
And if we do it more often, agents will likely follow this naturally. We
can also add hints to AGENTS.md, directing agents to look at similar PRs to
figure things out.
This way, we won't need to document anything that precise. Just what we've
always done: learn from others.
------
The window is 2026-05-09 to 2026-10-09: 4,839 merged PRs, of which 3,673
remain after cleanup. "Maintainer" means the 74 committers in breeze's
COMMITTERS list. Not counted: merge commits from "update branch", bot PRs,
backports, cherry-picked commits, and one PR where a maintainer wrote every
commit (a takeover).
┌─────────────────────────────────────────────────┬───────┬───────────────────────┬───────────────────────────────────────┐
│ │ PRs │ With maintainer
fixup │ Only an applied maintainer suggestion │
├─────────────────────────────────────────────────┼───────┼───────────────────────┼───────────────────────────────────────┤
│ All │ 3,673 │ 120 (3.3%)
│ 66 (1.8%) │
├─────────────────────────────────────────────────┼───────┼───────────────────────┼───────────────────────────────────────┤
│ Contributor-authored │ 1,796 │ 79 (4.4%)
│ 25 (1.4%) │
├─────────────────────────────────────────────────┼───────┼───────────────────────┼───────────────────────────────────────┤
│ Committer-authored (fixed by another committer) │ 1,877 │ 41 (2.2%)
│ 41 (2.2%) │
└─────────────────────────────────────────────────┴───────┴───────────────────────┴───────────────────────────────────────┘
Trend for contributor PRs: rising.
┌───────────────────┬────────────────────────────┐
│ Month │ Contributor PRs with fixup │
├───────────────────┼────────────────────────────┤
│ May │ 2.3% │
├───────────────────┼────────────────────────────┤
│ Jun │ 3.8% │
├───────────────────┼────────────────────────────┤
│ Jul │ 2.5% │
├───────────────────┼────────────────────────────┤
│ Aug │ 3.7% │
├───────────────────┼────────────────────────────┤
│ Sep │ 5.8% │
├───────────────────┼────────────────────────────┤
│ Oct (9 days only) │ 12.6% (16 of 127) │
└───────────────────┴────────────────────────────┘
For committer-authored PRs it stays around 1–2%, apart from 5% in May.
Size and who merges:
- There were 225 fixup commits in total, with a median of one per PR.
- In 72.5% of cases (87 of 120), a maintainer who pushed the fixup also
merged the PR. So it's mostly "fix it up and land it", not a hand-off.
Who pushes fixups (PRs / commits):
┌────────────────┬──────────┬─────────┐
│ Maintainer │ PRs │ Commits │
├────────────────┼──────────┼─────────┤
│ you (potiuk) │ 37 │ 47 │
├────────────────┼──────────┼─────────┤
│ shahar1 │ 12 │ 19 │
├────────────────┼──────────┼─────────┤
│ pierrejeambrun │ 11 │ 15 │
├────────────────┼──────────┼─────────┤
│ jason810496 │ 10 │ 24 │
├────────────────┼──────────┼─────────┤
│ uranusjr │ 10 │ 38 │
├────────────────┼──────────┼─────────┤
│ kaxil │ 9 │ 28 │
├────────────────┼──────────┼─────────┤
│ bbovenzi │ 7 │ 9 │
├────────────────┼──────────┼─────────┤
│ 12 others │ 1–6 each │ │
└────────────────┴──────────┴─────────┘
You account for about 30% of all fixed-up PRs.
What the fixups are, sorted roughly by commit title: tests 40, generic
fix/fixup 35, docs/changelog 23, static checks/lint/mypy 20, review
follow-ups 16, and 90 that don't fit those groups (mostly real code
changes).
Comparison: non-committers who are not the PR author commit to someone
else's PR in 1.6% of PRs.
Caveats:
- These are lower bounds. A fixup counts only when the commit's GitHub
author is the maintainer. Fixups committed under an email not linked to
their account, or force-pushed and squashed into the author's commits, are
missed.
- 9 PRs with more than 40 commits were only partly scanned.
- About 1 in 15 sampled "fixups" was still noise, such as a dependency bump
folded in.
------
J.
On Fri, Oct 9, 2026 at 12:15 PM Pierre Jeambrun <[email protected]>
wrote:
> I have been doing this for several years too.(not everyday but when I felt
> like this would help / wanted to do it)
>
> I’ve never had pushback from authors or sign of frustration, they were
> always happy I helped cross the finish line.
>
> (Probably because they opted in by ticking the box)
>
>
> I also believe this is common sense and do not need to be written down.
>
>
> On Fri 9 Oct 2026 at 10:30, Ash Berlin-Taylor <[email protected]> wrote:
>
> > The way I see it: It adds nothing but cognitive load to users, and extra
> > context tokens by being in AGENTS.md
> >
> > Every token we add to our docs _literally_ comes with a cost, and a cost
> > that is compounded against every round and every user that interacts with
> > the repo.
> >
> > You are saying “but what it someone complains or is unsure”. Do you have
> > any examples? Otherwise to me YAGNI applies.
> >
> > I am not against doing it, as I already said, I’ve been doing this for 8
> > years. I’m against writing it in the docs as in my mind it simply doesn’t
> > need to be said.
> >
> > > On 9 Oct 2026, at 00:43, Jarek Potiuk <[email protected]> wrote:
> > >
> > > The big difference is that it seems we have consensus on it, making it
> > into
> > > AGENTS.md will promote it as acceptable behaviour.
> > >
> > > But also will also it might save the queueing time, speed up merging
> > > process. All the things that I and others mentioned as positive
> effects.
> > >
> > > On Thu, Oct 8, 2026, 20:30 Ash Berlin-Taylor <[email protected]> wrote:
> > >
> > >> That’s _your_ choice on _your_ agent. That is precisely why ./
> > >> CLAUDE.local.md exists.
> > >>
> > >> What we get, is yet another thing that people have to read or skim
> over
> > >>
> > >
> > > What problem does it cause If this is something that they should be
> aware
> > > of? They will be better informed likely.
> > >
> > >
> > >> What’s next. We tell them that we might want them to make changes, or
> > ask
> > >> for clarification on the problem?
> > >
> > >
> > > Actually - the more we describe what we want - the more likely it will
> be
> > > that we will get what we asked for.
> > >
> > > Let's not reduce it to absurd, the discussion had shown that it is not
> > > obvious that it's acceptable practice, but in fact - it is. All that I
> > > propose to do is to explain that it is the case.
> > >
> > > I think we should focus on trying to find things that will help us to
> > deal
> > > with new reality we are in.
> > >
> > > And this is something that ideally we will get community members
> focused
> > on
> > > helping with - or at least not blocking such attempts when others offer
> > > their time and energy and enthuse others to help them.
> > >
> > > Let's just try those and a number of other things and see if it wil
> work.
> > >
> > > J
> > >
> > >
> > >>> On 8 Oct 2026, at 17:12, Jarek Potiuk <[email protected]> wrote:
> > >>>
> > >>> Also - what else will happen when we document it?
> > >>>
> > >>> My agent and agents of any maintainer will automatically assess
> > >>> whether the fixup is small and propose this as an action when you
> > >>> review the PR. Otherwise, if you want to do it, you need to override
> > >>> the agent's proposals.
> > >>>
> > >>> This will actually give time back to some maintainers and reduce one
> > >>> decision they can easily delegate to agents.
> > >>>
> > >>> What do we get if we don't (i.e what we've already lost a lot of time
> > >>> discussing) :
> > >>>
> > >>> About 200 bytes less in our repo.
> > >>>
> > >>> J.
> > >>>
> > >>>
> > >>>
> > >>> On Thu, Oct 8, 2026 at 6:02 PM Jarek Potiuk <[email protected]>
> wrote:
> > >>>>
> > >>>> It's not about the feature, but about acceptable use in our
> community
> > >>>> and capturing the community's understanding. Different communities
> > >>>> might have different "social agreement" here.
> > >>>>
> > >>>> What one community agrees is acceptable, another might disagree
> with.
> > >>>> Put yourself in the shoes of someone who contributes to several
> > >>>> projects. I personally contributed to about a 100 different projects
> > >>>> (in and out ASF) - in the next 3 months. And I could only do this
> > >>>> properly without getting push back or some "ivory tower" people
> > >>>> telling me, "But 3 years ago we discussed it and we agreed it is
> > >>>> fine," coming and scolding me for not following rules discussed in a
> > >>>> random discussion 3 years ago.
> > >>>>
> > >>>> And yes - it happened in Airflow a few times that people were
> scolded
> > >>>> for not following the rules that were not captured in contributions
> > >>>> guide.
> > >>>>
> > >>>> J
> > >>>>
> > >>>> On Thu, Oct 8, 2026 at 5:16 PM Ash Berlin-Taylor <[email protected]>
> > >> wrote:
> > >>>>>
> > >>>>>
> > >>
> >
> https://docs.github.com/en/pull-requests/how-tos/work-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork
> > >>>>>
> > >>>>> There you go, docs. Like I said, it’s a GH feature. They ticked the
> > >> box, they let us do it.
> > >>>>>
> > >>>>> And has anyone been surprised so far?
> > >>>>>
> > >>>>>
> > >>>>>> On 8 Oct 2026, at 16:06, Jarek Potiuk <[email protected]> wrote:
> > >>>>>>
> > >>>>>>> Put most directly: what would someone do differently having this
> > >>>>>> information, vs if they didn’t have it?
> > >>>>>>
> > >>>>>> They would not be surprised and raise their concerns - or if they
> > did
> > >> we
> > >>>>>> would direct them to the docs.
> > >>>>>>
> > >>>>>> On Thu, Oct 8, 2026 at 4:58 PM Ash Berlin-Taylor <[email protected]>
> > >> wrote:
> > >>>>>>
> > >>>>>>> Put most directly: what would someone do differently having this
> > >>>>>>> information, vs if they didn’t have it?
> > >>>>>>>
> > >>>>>>> This simply doesn’t need documenting, because it’s not something
> > _we
> > >> as a
> > >>>>>>> project_ do. It’s something some maintainers might do when they
> > feel
> > >> like
> > >>>>>>> it or choose to.
> > >>>>>>>
> > >>>>>>> None of the other things you mention below are even remotely
> > similar
> > >> to
> > >>>>>>> this.
> > >>>>>>>
> > >>>>>>> Editing a document isn’t done when there’s nothing left to add,
> > it’s
> > >> done
> > >>>>>>> when there is nothing left to take away.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> On 7 Oct 2026, at 14:27, Jarek Potiuk <[email protected]> wrote:
> > >>>>>>>>
> > >>>>>>>> Hi Ash and others,
> > >>>>>>>>
> > >>>>>>>>> Why does it need documenting? Our docs are already way, way WAY
> > too
> > >>>>>>> long.
> > >>>>>>>>
> > >>>>>>>> Tl;DR; Mostly to document "Whys" rather than follow cargo-cult
> > >> rules that
> > >>>>>>>> result from the whys - and make it easier to adapt them in the
> > >> future.
> > >>>>>>>>
> > >>>>>>>> Without documentation, neither AI agents nor new contributors
> will
> > >> know
> > >>>>>>> why
> > >>>>>>>> we are doing things and will continue rediscovering decisions we
> > >>>>>>>> already discussed and agreed upon. This makes it difficult to
> > >> challenge
> > >>>>>>> the
> > >>>>>>>> rules when better ways to follow the "whys" emerge in the
> future.
> > >>>>>>>>
> > >>>>>>>> In my view, our documentation is still not comprehensive enough
> > (and
> > >>>>>>> never
> > >>>>>>>> will be) comprehensive enough and has a number of gaps in our
> > >>>>>>>> "institutional" knowledge Capturing this knowledge—and ensuring
> it
> > >> is
> > >>>>>>>> searchable, unambiguous, and maintained—allows us to align on
> > >> basics and
> > >>>>>>>> focus on higher-level discussions.
> > >>>>>>>>
> > >>>>>>>> We have already seen this pay off with our recent agentic work.
> > The
> > >> ADRs
> > >>>>>>>> and guidelines maintainers added have significantly improved PR
> > >> quality,
> > >>>>>>> as
> > >>>>>>>> I tracked and clearly saw in my triage trials.
> > >>>>>>>>
> > >>>>>>>> With agents continuously keeping things in check, contributors
> no
> > >> longer
> > >>>>>>>> need to manually search through extensive documentation—a common
> > >> claim -
> > >>>>>>>> mostly true in the past: "nobody reads the docs.". People may
> read
> > >> even
> > >>>>>>>> less docs today, but their agents read and follow it, often
> > explain
> > >> them
> > >>>>>>>> why they do things they do - after reading that in our docs -
> > which
> > >> is a
> > >>>>>>>> classic "learn by doing" pattern. This reduces guesswork and
> > >> frustration
> > >>>>>>>> for new contributors. Instead of asking "Is this fine?" (or more
> > >>>>>>> frequently
> > >>>>>>>> being scolded for a rule they did not know existed), they can
> > >> straight
> > >>>>>>> away
> > >>>>>>>> find out "Why are we doing this?", and when they see a place for
> > >>>>>>>> improvement, they might challenge the way - or simply implement
> > new
> > >> ways
> > >>>>>>> by
> > >>>>>>>> following the whys -out spending much time with fighting the
> > status
> > >> quo.
> > >>>>>>>>
> > >>>>>>>> And then - they can ask even more - and more important - "why"
> > >> questions.
> > >>>>>>>> When those "why" questions arise, documenting the answers
> prevents
> > >> us
> > >>>>>>> from
> > >>>>>>>> having to get them asked and answer, freeing up space for more
> > >> impactful
> > >>>>>>>> discussions.
> > >>>>>>>>
> > >>>>>>>> Without documenting the reasoning behind our decisions, we risk
> > >> getting
> > >>>>>>>> stuck in cargo-cult patterns where rules are followed without
> > >>>>>>> understanding
> > >>>>>>>> why. Documenting "why" gives new contributors the context they
> > need
> > >> to
> > >>>>>>>> constructively challenge existing processes. And this is the
> only
> > >> way we
> > >>>>>>>> can grow: by continuously challenging and rediscovering better
> > ways
> > >> of
> > >>>>>>>> doing things.
> > >>>>>>>>
> > >>>>>>>> We saw this exact pattern with the introduction of Black,
> > pre-commit
> > >>>>>>> hooks,
> > >>>>>>>> and CI rules. We used to spend time arguing over formatting and
> > >> import
> > >>>>>>>> styles. Now, these are automated, and our contribution guides
> > >> explain the
> > >>>>>>>> "why" behind them rather than just enforcing the "how."
> > >>>>>>>>
> > >>>>>>>> This context also allows agents to fix issues autonomously and
> > >> update
> > >>>>>>>> documentation when parameters change for example or when tools
> get
> > >> new
> > >>>>>>>> capabilities - because they know "why" and can implement fixes
> and
> > >>>>>>> propose
> > >>>>>>>> improvements on their own - if the particular captured "tool
> call"
> > >> gets
> > >>>>>>>> wrong (happens all the time with our release processes now) -
> for
> > >> example
> > >>>>>>>> happened recently when flit got upgraded to version 4, agents
> > found
> > >> out
> > >>>>>>> and
> > >>>>>>>> fixed the issue, updated the docs, tested and compared the
> > packages
> > >>>>>>> before
> > >>>>>>>> and after - without me asking them for it. All that because our
> > >> release
> > >>>>>>>> docs and breeze docs explained "what" we want to achieve and
> "why"
> > >> - the
> > >>>>>>>> "how" could be changed autonomously by the agent in the event of
> > >> external
> > >>>>>>>> environment change.
> > >>>>>>>>
> > >>>>>>>> Documenting our decisions, the rationale behind them, rejected
> > >>>>>>>> alternatives, and exception boundaries has successfully
> eliminated
> > >>>>>>>> repetitive debates in the past (which I defeinitely do not miss)
> > and
> > >>>>>>> opened
> > >>>>>>>> us up for new, more important discussions, and we should
> continue
> > >> this
> > >>>>>>>> approach. Get better every single day - mostly by documenting
> and
> > >>>>>>>> automating what is important today, so that we make space for
> > >> things that
> > >>>>>>>> will come tomorrow.
> > >>>>>>>>
> > >>>>>>>> Best regards,
> > >>>>>>>> Jarek
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Oct 7, 2026 at 1:28 PM Ash Berlin-Taylor <
> [email protected]>
> > >> wrote:
> > >>>>>>>>
> > >>>>>>>>> Ah, so now here’s the possible point of contention:
> > >>>>>>>>>
> > >>>>>>>>> Why does it need documenting? Our docs are already way, way WAY
> > too
> > >>>>>>> long.
> > >>>>>>>>>
> > >>>>>>>>> I’ve been doing this _for years_. It’s up to the reviewer, and
> > is a
> > >>>>>>>>> natural part of GH PRs.
> > >>>>>>>>>
> > >>>>>>>>> -ash
> > >>>>>>>>>
> > >>>>>>>>>> On 7 Oct 2026, at 12:13, Jarek Potiuk <[email protected]>
> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> Thanks for the feedback everyone !
> > >>>>>>>>>>
> > >>>>>>>>>> Since this seems non-controversial (surprisingly) I will later
> > >> today or
> > >>>>>>>>>> tomorrow capture it in our contrbuting docs - so that our
> > >> contributors
> > >>>>>>>>> are
> > >>>>>>>>>> not surprised by it (or at least we can direct them to it). I
> > >> will open
> > >>>>>>>>> PR
> > >>>>>>>>>> later.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, Oct 7, 2026, 11:42 Jarek Potiuk <[email protected]>
> > wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Wed, Oct 7, 2026, 11:19 Natanel <[email protected]>
> > >> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> I think it's a very good idea, what we usually do (at our
> org)
> > >> is
> > >>>>>>> that
> > >>>>>>>>> for
> > >>>>>>>>>>>> small and minor changes, the reviewer adds suggestions, and
> > the
> > >> PR
> > >>>>>>>>> owner
> > >>>>>>>>>>>> can accept if he agrees, this also solves the org policy
> issue
> > >> IMO,
> > >>>>>>>>> maybe
> > >>>>>>>>>>>> a
> > >>>>>>>>>>>> good start is to encourage reviewers to leave suggestions
> for
> > >> small
> > >>>>>>>>>>>> changes
> > >>>>>>>>>>>> rather than comments.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Oh absolutely :). I think this is the 'gradation': comment/
> > >> online
> > >>>>>>>>> comment
> > >>>>>>>>>>> (blocking unless resolved currently) / inline comment with
> > >> suggestion
> > >>>>>>> /
> > >>>>>>>>>>> direct fixup.
> > >>>>>>>>>>>
> > >>>>>>>>>>> And we should IMHO choose whatever is appropriate depending
> on
> > >> 'scope'
> > >>>>>>>>> of
> > >>>>>>>>>>> fix and urgency of the PR - for example I am.much more info
> > >> fixups
> > >>>>>>> just
> > >>>>>>>>>>> before preparing provider's release.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>> It is limited to small changes, but from my point of view,
> an
> > >> "almost
> > >>>>>>>>>>>> done"
> > >>>>>>>>>>>> pr only needs minor fixups.
> > >>>>>>>>>>>> In case the PR owner does not reply and the PR is stale this
> > >> might
> > >>>>>>> not
> > >>>>>>>>>>>> work, yet I think users with read access should be able to
> > >> accept
> > >>>>>>> those
> > >>>>>>>>>>>> suggestions as well
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Any thoughts about this proposal?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Wed, Oct 7, 2026, 11:59 Ash Berlin-Taylor <
> [email protected]>
> > >> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Org policy prevents us from changing this I think. Or at
> > least
> > >> I
> > >>>>>>> have
> > >>>>>>>>>>>>> never been able to find a setting that changes this :(
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On 6 Oct 2026, at 17:52, Jarek Potiuk <[email protected]>
> > >> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Plus isn’t this a configurable setting? i.e. when I open
> a
> > >> PR from
> > >>>>>>>>> my
> > >>>>>>>>>>>>> fork I can “allow edits from maintainers” <
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>
> >
> https://docs.github.com/en/pull-requests/how-tos/work-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork
> > >>>>>>>>>>>>> ,
> > >>>>>>>>>>>>> and you could argue I’m opting into this approach by
> checking
> > >> that
> > >>>>>>>>> box.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Yes. It is. For example all astronomer people contributing
> > >> from
> > >>>>>>>>>>>>>> astronomer repo have it disabled :D
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Tue, Oct 6, 2026 at 6:47 PM Julian LaNeve via dev
> > >>>>>>>>>>>>>> <[email protected]> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> This may be a personal thing but when I’ve made
> > >> contributions to
> > >>>>>>>>>>>> other
> > >>>>>>>>>>>>> OSS projects I generally care more about getting the change
> > in
> > >> than
> > >>>>>>> I
> > >>>>>>>>> am
> > >>>>>>>>>>>>> attached to my particular code / implementation. So I
> always
> > >> look at
> > >>>>>>>>> it
> > >>>>>>>>>>>> as
> > >>>>>>>>>>>>> a win-win when someone takes my contribution and runs with
> it
> > >> - I
> > >>>>>>> can
> > >>>>>>>>>>>>> always go back and look at the changes to learn if I want.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Plus isn’t this a configurable setting? i.e. when I open
> a
> > >> PR from
> > >>>>>>>>> my
> > >>>>>>>>>>>>> fork I can “allow edits from maintainers” <
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>
> >
> https://docs.github.com/en/pull-requests/how-tos/work-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork
> > >>>>>>>>>>>>> ,
> > >>>>>>>>>>>>> and you could argue I’m opting into this approach by
> checking
> > >> that
> > >>>>>>>>> box.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Oct 6, 2026, at 12:40 PM, Jarek Potiuk <
> > [email protected]
> > >>>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Just to share my experience - I think I did it many
> times
> > >> (more
> > >>>>>>>>> than
> > >>>>>>>>>>>>>>>> 50) and never got any push-back. But of course that
> might
> > be
> > >>>>>>>>> because
> > >>>>>>>>>>>>>>>> people are shy / afraid to oppose me (I have a
> reputation
> > >> for
> > >>>>>>> being
> > >>>>>>>>>>>>>>>> difficult).
> > >>>>>>>>>>>>>>>> But when you think about it, there is no big **issue**:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> * merging means that is no longer **author's code** - it
> > >> becomes
> > >>>>>>>>>>>>>>>> "community code"
> > >>>>>>>>>>>>>>>> * maintainer's job is to make sure that the code is good
> > and
> > >>>>>>>>>>>>>>>> maintainable (this approach makes it works)
> > >>>>>>>>>>>>>>>> * authorship remains - but also it's there is a
> co-author
> > >> (this
> > >>>>>>> is
> > >>>>>>>>>>>>>>>> what is recorded in commit)
> > >>>>>>>>>>>>>>>> * if the committer does not agree with author, they can
> > >> merge
> > >>>>>>>>> follow
> > >>>>>>>>>>>>>>>> up commit changing things anyway
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> So - putting aside some possible personal ("it's my own,
> > my
> > >>>>>>>>>>>> precious")
> > >>>>>>>>>>>>>>>> approach - I see no disadvantages of such an approach.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> J.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Tue, Oct 6, 2026 at 6:28 PM Ferruzzi, Dennis via dev
> > >>>>>>>>>>>>>>>> <[email protected]> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I've definitely considered it, but have not yet done
> > it. I
> > >>>>>>> think
> > >>>>>>>>>>>> I'm
> > >>>>>>>>>>>>> concerned that the contributor may take it the wrong way
> > >> rather than
> > >>>>>>>>> "I
> > >>>>>>>>>>>>> just fixed it while I was in there" and "it took just as
> long
> > >> to fix
> > >>>>>>>>> it
> > >>>>>>>>>>>> as
> > >>>>>>>>>>>>> it would have taken to explain it".
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> - ferruzzi
> > >>>>>>>>>>>>>>>>> ________________________________
> > >>>>>>>>>>>>>>>>> From: Jarek Potiuk <[email protected]>
> > >>>>>>>>>>>>>>>>> Sent: Tuesday, October 6, 2026 1:17 AM
> > >>>>>>>>>>>>>>>>> To: [email protected] <[email protected]>
> > >>>>>>>>>>>>>>>>> Subject: [EXT] [DISCUSS] Merging "almost" ready PRs
> with
> > >>>>>>>>>>>>> maintainer-fixups from contributors
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> CAUTION: This email originated from outside of the
> > >> organization.
> > >>>>>>>>> Do
> > >>>>>>>>>>>>> not click links or open attachments unless you can confirm
> > the
> > >>>>>>> sender
> > >>>>>>>>>>>> and
> > >>>>>>>>>>>>> know the content is safe.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> AVERTISSEMENT: Ce courrier électronique provient d’un
> > >> expéditeur
> > >>>>>>>>>>>>> externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce
> > >> jointe
> > >>>>>>> si
> > >>>>>>>>>>>> vous
> > >>>>>>>>>>>>> ne pouvez pas confirmer l’identité de l’expéditeur et si
> vous
> > >> n’êtes
> > >>>>>>>>> pas
> > >>>>>>>>>>>>> certain que le contenu ne présente aucun risque.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Hello everyone,
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> In order to improve our "agentic AI" workflows, I have
> > >> recently
> > >>>>>>>>>>>>>>>>> changed my approach for pull requests that are "almost
> > >> ready"
> > >>>>>>> and
> > >>>>>>>>>>>> need
> > >>>>>>>>>>>>>>>>> only small fixes, such as mechanical conflicts, typos,
> or
> > >> minor
> > >>>>>>>>>>>>>>>>> comment updates. I would love to get your feedback on
> > this
> > >>>>>>>>> pattern.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Previously, when a PR had one or two minor issues, I
> > would
> > >>>>>>> approve
> > >>>>>>>>>>>> it,
> > >>>>>>>>>>>>>>>>> add inline comments specifying the necessary changes,
> and
> > >> ask
> > >>>>>>> the
> > >>>>>>>>>>>>>>>>> author to fix them. Recently, I have often adopted this
> > >> approach
> > >>>>>>>>>>>>>>>>> instead:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> - Make inline comments explaining the issue
> > >>>>>>>>>>>>>>>>> - Rebase and remove conflicts if needed
> > >>>>>>>>>>>>>>>>> - Apply the fixup myself (pushing directly to the
> > >> contributor's
> > >>>>>>>>>>>>> branch).
> > >>>>>>>>>>>>>>>>> - Comment and resolve my own inline comments.
> > >>>>>>>>>>>>>>>>> - Approve and merge once CI checks pass.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I only do this for small gaps, edge cases, mechanical
> > >> fixes, or
> > >>>>>>>>>>>>>>>>> documentation updates that do not alter the substance
> of
> > >> the PR.
> > >>>>>>>>>>>> The
> > >>>>>>>>>>>>>>>>> PR remains primarily the author's work, with minor
> > >> co-authored
> > >>>>>>>>>>>> fixes.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> This pattern offers several benefits:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> - Efficiency: With agentic-assisted reviews, the AI
> > >> already has
> > >>>>>>>>> the
> > >>>>>>>>>>>>>>>>> context and proposed fix, taking only seconds to apply
> > and
> > >> push.
> > >>>>>>>>>>>>>>>>> - Faster Merges: Eliminates additional review
> roundtrips
> > >> and
> > >>>>>>>>> avoids
> > >>>>>>>>>>>>>>>>> new conflicts from interim merges.
> > >>>>>>>>>>>>>>>>> - Fewer Iterations: Prevents extra back-and-forth if a
> > >> comment
> > >>>>>>> is
> > >>>>>>>>>>>>>>>>> misunderstood or incompletely fixed.
> > >>>>>>>>>>>>>>>>> - Keeps Educational Value: The author receives both an
> > >>>>>>> explanation
> > >>>>>>>>>>>>>>>>> of the issue and code for the solution.
> > >>>>>>>>>>>>>>>>> - PR Capacity: Frees up contributor PR slots sooner.
> > >>>>>>>>>>>>>>>>> - Throughput: Helps us process a higher volume of PRs
> > more
> > >>>>>>>>> quickly.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> The main tradeoff is that the author learns by reading
> > >> rather
> > >>>>>>> than
> > >>>>>>>>>>>>>>>>> doing, which could potentially lead to a more relaxed
> > >> approach
> > >>>>>>> to
> > >>>>>>>>>>>>>>>>> minor details. However, if restricted strictly to
> minor,
> > >>>>>>>>> mechanical
> > >>>>>>>>>>>>>>>>> adjustments—while still using "Request Changes" for
> > larger
> > >>>>>>> gaps—I
> > >>>>>>>>>>>>>>>>> believe the benefits outweigh the downsides.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I would love to hear what others—especially
> contributors
> > >> and
> > >>>>>>>>> fellow
> > >>>>>>>>>>>>>>>>> maintainers—think about this workflow.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Best regards,
> > >>>>>>>>>>>>>>>>> Jarek
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >> ---------------------------------------------------------------------
> > >>>>>>>>>>>>>>>>> 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]
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >> ---------------------------------------------------------------------
> > >>>>>>>>> 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]
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
