8 Jul
2026
8 Jul
'26
4:46 a.m.
On 08/07/2026 11.45, Guus der Kinderen wrote:
Hi Ralph,
Two things:
First on the review gate: Dave has made the point that it sits too
early, and you've added that XEPs used to be changed by discussing
with the author rather than by PR. Moving that gate later (light
review at intake, with the deeper reading happening as people actually
engage with a spec) is a change we could actually make. It has the
property that nothing gets a careful reading until someone cares
enough to give it one, which is exactly the wrong incentive for anyone
submitting in volume. It would help whether or not that volume
materialises. It doesn't require us to agree about AI at all. Before
committing to it, though, I'd want to understand why we moved in the
other direction in the first place. Presumably it served some purpose.
I think
because PRs (in GitHub) from interaction perspective is much
easier to deal with and coders are familiar with it. I.e. when you
submit a PR, you have a malleable chain of modifications (to improve the
change during the interactive review process), you can comment on
specific parts of those modifications, mark when particular comments are
resolved, etc., and you can preserve that process both in the repository
(if you do branch merges) and in GitHub's ticketing system.
The prior mechanism was mostly discussing changes on this list
(preferably) and in private and public conversations on IRC (initially)
and XMPP.
I do not think that lightening the triage affects submission volume,
though. I also assume in all my previous comments that AI-assisted
contributions are still done by humans and not automated as well.
Lightening the triage does provide a way to handle increased volume.
Second: you've twice invited a PR against XEP-0143
using your
phrasing. I've opened one: https://github.com/xsf/xeps/pull/1552. It's
your sentence, in the submission process rather than the
pre-submission advice, since the latter is explicitly advisory. It's
deliberately not AI-specific and it doesn't settle anything else here.
I'd rather it merged on its own merits than became a proxy for the
wider argument.
Thanks for the PR. As the mediate author / human prompter, it would
be
weird to approve the change, but I do support it.
You asked Goffi why a human-authored document
wouldn't need the same
thoroughness. I think that's unfair to him. Reviewers have always read
with priors. You read a new contributor more carefully than a familiar
one, and for a familiar contributor you may give more attention to
certain aspects than to others. Knowing a submission came from an LLM
tells you to go and check the references. That's useful information,
if you have it. My objection isn't that disclosure would tell us
nothing, it's that I don't expect it to be accurate in the cases where
it matters most. Those are separate arguments, and I think they've
been getting mixed up.
Right, individuals gather reputation. Does a known author
that increases
its use of AI in the generation of their contribution lower their
reputation because of that? I personally expect from any known
contributor that the quality of their work does not decrease.
Does / should disclosure materially affect the review process for
newcomers? If so, how can you trust their disclosure one way or the other?
Also, I don't think that it is the role of a reviewer (in general,
including code) to become experts on all details of contributions. This
includes the XMPP Council. Like in the IETF, the responsibility for the
quality and correctness of a given specification is shared between the
authors, the Standards-JIG, and the Council. Besides managing our
standards process, the Council exists to provide a set of people that
have the specific task to provide technical advice and in general review
contributions, on top of the wider community view. A dedicated
collection of additional eyes, so to say.
If the current understanding is that the Council is fully responsible
for the outcome, then I believe that is undesirable and we need to make
the role of the Council more explicit in this regard.
ralphm