Re: We should require AI disclosure

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
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]