Re: We should require AI disclosure
Guus der Kinderen <[email protected]> Wed, 8 Jul 2026 13:09:14 +0200
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <CAMJaV9=Ny9tqG4dxLjZpRqZDvvK8=pnj4mjCyoHz1bcM4FBD5A@mail.gmail.com> |
--===============7823954700141804432== Content-Type: multipart/alternative; boundary="00000000000069941b0656178aa8" --00000000000069941b0656178aa8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ralph, I agree Council is not fully responsible, and I'd support saying so explicitly. However, I think that XEP-0001 is already quite explicit in this (requiring rough consensus, running code, Council approval reads like the "shared responsibility" that we're talking about). I'm not sure there's a gap. If you think the current _understanding_ differs from the current text, that seems worth saying out loud on the list. Kind regards, Guus On Wed, Jul 8, 2026 at 12:47=E2=80=AFPM Ralph Meijer <[email protected]> wrote: > 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] > --00000000000069941b0656178aa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Ralph,<br><br>I agree Council is not fully responsible,= and I'd support saying so explicitly. However, I think that XEP-0001 i= s already quite explicit in this (requiring rough consensus, running code, = Council approval reads like the "shared responsibility" that we&#= 39;re talking about). I'm not sure there's a gap.<br><br>If you thi= nk the current _understanding_ differs from the current text, that seems wo= rth saying out loud on the list.<br><br>Kind regards,<br><br>=C2=A0 Guus</d= iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl= ass=3D"gmail_attr">On Wed, Jul 8, 2026 at 12:47=E2=80=AFPM Ralph Meijer <= ;<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<br></div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:= 1px solid rgb(204,204,204);padding-left:1ex">On 08/07/2026 11.45, Guus der = Kinderen wrote:<br> > Hi Ralph,<br> ><br> > Two things:<br> ><br> > First on the review gate: Dave has made the point that it sits too <br= > > early, and you've added that XEPs used to be changed by discussing= <br> > with the author rather than by PR. Moving that gate later (light <br> > review at intake, with the deeper reading happening as people actually= <br> > engage with a spec) is a change we could actually make. It has the <br= > > property that nothing gets a careful reading until someone cares <br> > enough to give it one, which is exactly the wrong incentive for anyone= <br> > submitting in volume. It would help whether or not that volume <br> > materialises. It doesn't require us to agree about AI at all. Befo= re <br> > committing to it, though, I'd want to understand why we moved in t= he <br> > other direction in the first place. Presumably it served some purpose.= <br> I think because PRs (in GitHub) from interaction perspective is much <br> easier to deal with and coders are familiar with it. I.e. when you <br> submit a PR, you have a malleable chain of modifications (to improve the <b= r> change during the interactive review process), you can comment on <br> specific parts of those modifications, mark when particular comments are <b= r> resolved, etc., and you can preserve that process both in the repository <b= r> (if you do branch merges) and in GitHub's ticketing system.<br> <br> The prior mechanism was mostly discussing changes on this list <br> (preferably) and in private and public conversations on IRC (initially) <br= > and XMPP.<br> <br> I do not think that lightening the triage affects submission volume, <br> though. I also assume in all my previous comments that AI-assisted <br> contributions are still done by humans and not automated as well. <br> Lightening the triage does provide a way to handle increased volume.<br> <br> > Second: you've twice invited a PR against XEP-0143 using your <br> > phrasing. I've opened one: <a href=3D"https://github.com/xsf/xeps/= pull/1552" rel=3D"noreferrer" target=3D"_blank">https://github.com/xsf/xeps= /pull/1552</a>. It's <br> > your sentence, in the submission process rather than the <br> > pre-submission advice, since the latter is explicitly advisory. It'= ;s <br> > deliberately not AI-specific and it doesn't settle anything else h= ere. <br> > I'd rather it merged on its own merits than became a proxy for the= <br> > wider argument.<br> Thanks for the PR. As the mediate author / human prompter, it would be <br> weird to approve the change, but I do support it.<br> <br> > You asked Goffi why a human-authored document wouldn't need the sa= me <br> > thoroughness. I think that's unfair to him. Reviewers have always = read <br> > with priors. You read a new contributor more carefully than a familiar= <br> > one, and for a familiar contributor you may give more attention to <br= > > certain aspects than to others. Knowing a submission came from an LLM = <br> > tells you to go and check the references. That's useful informatio= n, <br> > if you have it. My objection isn't that disclosure would tell us <= br> > nothing, it's that I don't expect it to be accurate in the cas= es where <br> > it matters most. Those are separate arguments, and I think they've= <br> > been getting mixed up.<br> Right, individuals gather reputation. Does a known author that increases <b= r> its use of AI in the generation of their contribution lower their <br> reputation because of that? I personally expect from any known <br> contributor that the quality of their work does not decrease.<br> <br> Does / should disclosure materially affect the review process for <br> newcomers? If so, how can you trust their disclosure one way or the other?<= br> <br> Also, I don't think that it is the role of a reviewer (in general, <br> including code) to become experts on all details of contributions. This <br= > includes the XMPP Council. Like in the IETF, the responsibility for the <br= > quality and correctness of a given specification is shared between the <br> authors, the Standards-JIG, and the Council. Besides managing our <br> standards process, the Council exists to provide a set of people that <br> have the specific task to provide technical advice and in general review <b= r> contributions, on top of the wider community view. A dedicated <br> collection of additional eyes, so to say.<br> <br> If the current understanding is that the Council is fully responsible <br> for the outcome, then I believe that is undesirable and we need to make <br= > the role of the Council more explicit in this regard.<br> <br> ralphm<br> _______________________________________________<br> Standards mailing list -- <a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a><br> </blockquote></div> --00000000000069941b0656178aa8-- --===============7823954700141804432== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected] --===============7823954700141804432==--