Hi all,
Some thoughts, having read the thread through again.
On disclosure: I understand the appeal. Mattj puts the strongest version of the case: that we're currently in the dark about how these tools are being used in our community. My hesitation is with making it a requirement. A requirement will mostly be honoured by people who aren't producing the submissions we broadly agree we want to stop, while the people producing those are unlikely to honour it. Without assignable consequences it doesn't bite, and my worry is that it mainly burdens contributors who are making perfectly good use of these tools. Goffi points to llama.cpp and CPython. I don't know enough about how those requirements work in practice to say whether they transfer here. Both, I suppose, are handling code contributions with automated test suites behind them, which is maybe a rather different review problem to ours?
One thing I think we should do regardless: Ralph proposed a sentence for XEP-0143, that authors must understand, verify, and take responsibility for every contribution they submit. That seems worth having written down whatever else we decide, so I've opened a PR for it:
https://github.com/xsf/xeps/pull/1552. It is deliberately not AI-specific, and is not intended to settle anything else in this thread.
Which brings me to what I think is the actual problem. One of the XSF's most valuable assets is the volunteering force that helps us achieve our goals. We have not historically done a great job at preventing burnout among those volunteers, and we need to do better. If we do start receiving large volumes of AI-generated slop (and I don't think that has happened yet, but we would be wise to prepare) it carries a significant risk of adding to those burdens. Kev's point about the Editor role, and about the effort asymmetry between generating and reviewing a submission, seems to me the concrete harm we should be organising around. Not copyright, and not disclosure for its own sake.
So rather than "disclose AI", I'd like us to think about what we actually need in order to identify and handle low-quality submissions at volume, whatever produced them, AI or humans. Two things I think we need in order to have that conversation properly:
First, prior art. Goffi, you're the one with the most energy on this and you're seeing it from the Council side. Would you be willing to take this on? Kev hinted at the GSoC mentor discussions this year, and the IETF has apparently seen entire suites of AI-generated Internet Drafts. Other organisations are dealing with this right now, and I'd like to know what they've tried and how it worked out before we invent our own approach. It's well-bounded work, and if it comes back showing that disclosure requirements are doing real work elsewhere, that's an argument I'd want to hear and one that would carry weight with Board.
Second, procedure. If we identify a submission as slop, what happens? I think we need to guard in two directions at once: against volunteers having to process slop, and against submitters being rejected bluntly ("computer says no").
MSavoritias made a point earlier: consensus is unlikely to arrive on its own if we simply keep talking. I said in May that I preferred to see concrete, actionable proposals before this went to Board, and I still think that's right, but I'm aware that's easy to say and harder to act on, and I've not done much acting on it myself.
To answer the question Goffi has now put twice: I don't think we're ready for Board yet, and I want to be honest that this is the second time I've said so. What I think would change that is a concrete proposal with the prior art behind it. That's not far off (and the PR above already is a small piece of it).
Kind regards,
Guus