[qinsoon]

No description provided.

[qinsoon]

We had some discussion on Friday. I hope I have captured what we discussed in this draft PR. If I missed anything, please feel free to add it. @wks @steveblackburn

This is still a draft PR for now. Feedback from anyone is very welcome.

[k-sareen]

Looks mostly good to me, but I strongly recommend not allowing AI-generated text (bug/PR descriptions, design documents, README, etc.). I think any prose that another person will read should NOT be written by LLMs (see here for an article about it).

I've also seen someone online say (which I agree with):

Copying and pasting Claude responses into Slack or an email directly shifts the burden of comprehension and understanding to everyone else, and worse, risks skipping that step for yourself.

(Also I think disclosure should be required, not for a witch-hunt, but for accountability).

[no-defun-allowed]

I strongly recommend not allowing AI-generated text (bug/PR descriptions, design documents, README, etc.

I concur; I think also Claude (at least) has a rather strained writing style which can be simultaneously very dense while saying very little. See for example the comment rewritten by this patch to SBCL; "the GC-private cons caller passes NULL" is a very dense way of documenting something (what's the "GC-private cons caller"? How is NULL passed?) but somehow nothing in particular. (That kind of documentation should be in the header file anyway!)

My general policy on LLM usage is "never for anything serious", and I think MMTk is serious, so I am rather far on the AI-disinclined end of everyone involved here. A lot about actually reading the LLM output is very user-hostile and it's far from my favourite way to spend my time. That said, that experience usually comes from when people don't check the output themselves or don't hold it to a high standard, and I think this policy should prevent such experiences.

[qinsoon]

I strongly recommend not allowing AI-generated text (bug/PR descriptions, design documents, README, etc.). I think any prose that another person will read should NOT be written by LLMs (see here for an article about it).

I understand your point. I am strongly against directly copying and posting LLM's raw output for others to review. However, in my opinion, there is a difference between raw output and output after multiple iterations with human inputs. The doc in this PR was produced/generated by AI, but I had done 20+ iterations with AI to make sure I was happy with everything in the text. I don't feel this kind of AI-generated/assited text would cause troubles for reviewers to read, and I don't feel rewriting it in my own words (just to avoid AI-generated text) would improve its readability, especially given that English is not my native language. Plus it would also take more time to rewrite.

I hoped that emphasizing the responsibility of the human account holder and requiring contributors to review the output would be sufficient to avoid this issue. But we might need to be more explicit on this rule.

(Also I think disclosure should be required, not for a witch-hunt, but for accountability).

Most projects require disclosure. I am okay with it.

As for 'accountability', the doc already requires a human behind the account and requires the human to be responsible for the contribution. Adding 'co-authored-by' won't shift the responsibility from the human to the AI. This is intentional -- we don't want arguments like 'the AI made this mistake, not me'. A human is responsible for the change he submits, no matter who/what produced the change.

I originally made disclosure optional, as I felt it aligned more with our attitude on 'we review the content, not the tool'. If we truly check and review the content, does the disclosure really matter?

Besides, disclosure may introduce bias. Imaging reviewing the same PR (e.g. this PR) with and without a 'co-authored-by: claude' line: would that change your review? If so, that is bias, because the content is the same.

Given all these said, I am okay with requiring AI-use disclosure.

[k-sareen]

Yes I agree. We basically want to discourage low-quality contributions. Iterating with an AI is probably fine, but then we should mention the acceptable criteria for AI-generated prose. At the very least, we should disallow raw outputs.

Re: disclosure. I don't think the commit trailers are required, but mentioning your AI use (and how you used it) can be helpful to reviewers too imo (for example how you mentioned iterating with AI in your comment above).

[qinsoon]

I made some changes:

1. Emphasize that raw output from AI is rarely good, and self-review and iteration is expected.
2. Emphasize 'responsibility' in CONTRIBUTING.md
3. Change self-review from 'required' to 'expected'. We discussed this along with our policy about AI disclosure. The conclusion was that we can't verify whether people did self-review or not, and they used AI or not. Based on the principle of 'Don't make rules you can't enforce', we don't require either: we expect self-review, and AI disclosure is still optional.

[wks]

LGTM