Re: We should require AI disclosure

--===============6961325972658898225==
Content-Type: multipart/alternative; boundary="000000000000f68e02065693bbdb"

--000000000000f68e02065693bbdb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

I said I'd do the prior-art survey. It's here:
https://wiki.xmpp.org/web/AI_contribution_policies_in_other_projects

It's a wiki page. Please correct it directly.

The main caveat: almost none of this evidence is about standards. Of the
many organisations that are cataloged, by far most are code projects, where
CI catches some of what a reviewer otherwise would. The analogies may not
stretch far.

Three things that seemed relevant here. Ghostty required AI disclosure from
August 2025, for the reason Mattj gives. They still do, and have since
added a vouching system for first-time contributors as well. OpenJDK and
GraalVM are both Oracle projects whose contributors sign the same
agreement, and they published opposite policies six weeks apart. And curl
reopened the bug bounty it closed in January: volume hadn't fallen, but the
reports had stopped being wrong, which Stenberg attributes to the models
improving.

Kind regards,

Guus

On Thu, Jul 9, 2026 at 6:21=E2=80=AFPM Badri Sunderarajan <badrihippo@disro=
ot.org>
wrote:

> Hi all,
>
> Firstly, thank you to MSavoritias (and Dave) for bringing focus to what
> is actually the issue here: not the fact that something was created
> using a certain technology or other but the fact that it is mindless
> slop. I actually started composing an email to that effect earlier this
> morning, but got a bit overwhelmed by all the nuances, so I'm thankful
> to the others who managed to make a better job of it than I :-)
>
> > This does introduce a trade-off: For someone like Edward,
> > self-described as being a newcomer writing in a second language, this
> > can be a hurdle. A good submission from someone not yet accustomed to
> > interacting with the community may struggle to gain traction, because
> > seeking that engagement is harder for them.
> >
> > That said, requiring some minimal level of interaction before asking
> > Council to spend significant review effort doesn't seem unreasonable
> > to me. I mainly wanted to call out that trade-off to see whether it's
> > something we're comfortable with accepting.
>
> While still leaving that trade-off on the table for everyone to think
> about, I wonder if this might not be a positive change in other ways.
>
> We have been talking in the past about encouraging more participation in
> the standards list. Now we will have an incentive for submitters to
> actually go out there and talk to people (to encourage more visible
> discussion about the XEP) rather than sitting around waiting for the
> Council to respond. This is an area where people can participate in a
> less technical way as well ("hey it would be neat if my app could have
> this feature" rather than the more technical "wait so how would that
> work with X, Y, Z existing XEPs" that we have at the moment). I know
> this can happen even without the additional "incentive" but it isn't,
> and maybe this will be what pushes it.
>
> (The other possibility is that the mailing list and MUCs get filled with
> mindless-slop "discussions" as well, but hopefully "you have to also
> text us" will be a decent barrier and I suspect the community will be
> adept at weeding out any garbage that does make it through.)
>
> ~Badri
>
>

--000000000000f68e02065693bbdb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<br><br>I said I&#39;d do the prior-art survey. It&=
#39;s here: <a href=3D"https://wiki.xmpp.org/web/AI_contribution_policies_i=
n_other_projects">https://wiki.xmpp.org/web/AI_contribution_policies_in_oth=
er_projects</a><br><br>It&#39;s a wiki page. Please correct it directly.<br=
><br>The main caveat: almost none of this evidence is about standards. Of t=
he many organisations that are cataloged, by far most are code projects, wh=
ere CI catches some of what a reviewer otherwise would. The analogies may n=
ot stretch far.<br><br>Three things that seemed relevant here. Ghostty requ=
ired AI disclosure from August 2025, for the reason Mattj gives. They still=
 do, and have since added a vouching system for first-time contributors as =
well. OpenJDK and GraalVM are both Oracle projects whose contributors sign =
the same agreement, and they published opposite policies six weeks apart. A=
nd curl reopened the bug bounty it closed in January: volume hadn&#39;t fal=
len, but the reports had stopped being wrong, which Stenberg attributes to =
the models improving.<br><br>Kind regards,<br><br>Guus</div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Thu, Jul 9, 2026 at 6:21=E2=80=AFPM Badri Sunderarajan &lt;<a href=3D"=
mailto:[email protected]">[email protected]</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
Firstly, thank you to MSavoritias (and Dave) for bringing focus to what <br=
>
is actually the issue here: not the fact that something was created <br>
using a certain technology or other but the fact that it is mindless <br>
slop. I actually started composing an email to that effect earlier this <br=
>
morning, but got a bit overwhelmed by all the nuances, so I&#39;m thankful =
<br>
to the others who managed to make a better job of it than I :-)<br>
<br>
&gt; This does introduce a trade-off: For someone like Edward, <br>
&gt; self-described as being a newcomer writing in a second language, this =
<br>
&gt; can be a hurdle.=C2=A0A good submission from someone not yet accustome=
d to <br>
&gt; interacting with the community may struggle to gain traction, because =
<br>
&gt; seeking that engagement is harder for them.<br>
&gt;<br>
&gt; That said, requiring some minimal level of interaction before asking <=
br>
&gt; Council to spend significant review effort doesn&#39;t seem unreasonab=
le <br>
&gt; to me. I mainly wanted to call out that trade-off to see whether it&#3=
9;s <br>
&gt; something we&#39;re comfortable with accepting.<br>
<br>
While still leaving that trade-off on the table for everyone to think <br>
about, I wonder if this might not be a positive change in other ways.<br>
<br>
We have been talking in the past about encouraging more participation in <b=
r>
the standards list. Now we will have an incentive for submitters to <br>
actually go out there and talk to people (to encourage more visible <br>
discussion about the XEP) rather than sitting around waiting for the <br>
Council to respond. This is an area where people can participate in a <br>
less technical way as well (&quot;hey it would be neat if my app could have=
 <br>
this feature&quot; rather than the more technical &quot;wait so how would t=
hat <br>
work with X, Y, Z existing XEPs&quot; that we have at the moment). I know <=
br>
this can happen even without the additional &quot;incentive&quot; but it is=
n&#39;t, <br>
and maybe this will be what pushes it.<br>
<br>
(The other possibility is that the mailing list and MUCs get filled with <b=
r>
mindless-slop &quot;discussions&quot; as well, but hopefully &quot;you have=
 to also <br>
text us&quot; will be a decent barrier and I suspect the community will be =
<br>
adept at weeding out any garbage that does make it through.)<br>
<br>
~Badri<br>
<br>
</blockquote></div>

--000000000000f68e02065693bbdb--

--===============6961325972658898225==
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]

--===============6961325972658898225==--