Add AI agent disclosure and changelog to PR template

[sffc]

wdyt?

[Manishearth]

Is the intention for this to be for newcomers? And known contributors can blank it out and be clear about AI in any way they feel makes the most sense?

I like this. We should remember to blank it when merging (I think?) but I think it's a good idea.

I'd rather not have to tick this box every time I make a PR but if your intent is for everyone to do it I think it's...fine.

[sffc]

Is the intention for this to be for newcomers? And known contributors can blank it out and be clear about AI in any way they feel makes the most sense?

Yes

We should remember to blank it when merging (I think?)

I think it's okay for the commit log to contain a string describing the use of AI. It seems verbose for it to contain all three options with one of them being ticked in Markdown syntax. Suggestions?

[Manishearth]

"if one of the AI check boxes is checked, reviewers should try to delete the other lines before merging" (as soft guidance for reviewers, not something we have to enforce)

I agree that having the full checklist there is overkill

[sffc]

I changed the format and added a changelog section.

[robertbastian]

I don't care if contributors use tools to generate PRs. The PR author is responsible for all code they send for review, period.

This is why I also don't like @sffc's attitude on his AI generated PRs that this is not his but Gemini's code and therefore he won't address feedback (like #7534 (comment)).

This PR has the added problem of putting a lot of process boilerplate in PR descriptions that will end up in commit messages.

[Manishearth]

@sffc As I said Friday I plan to write up a plan for the changelog thing and see how people feel. I'd like an opportunity to do that before we start doing the template.

[Manishearth]

Though I guess there's no harm in having some changelog template we can always change it later

[sffc]

I don't care if contributors use tools to generate PRs. The PR author is responsible for all code they send for review, period.

Given the rapid increase in third-party contributors, which I suspect has a causal relationship with the rapid increase in AI coding tools, I want more transparency in this area.

This is why I also don't like @sffc's attitude on his AI generated PRs that this is not his but Gemini's code and therefore he won't address feedback (like #7534 (comment)).

My attitudes toward AI coding tools are rapidly evolving, and we did end up resolving that conflict.

This PR has the added problem of putting a lot of process boilerplate in PR descriptions that will end up in commit messages.

I agreed and already fixed this by replacing the bulleted list by a single line.

[robertbastian]

Given the rapid increase in third-party contributors, which I suspect has a causal relationship with the rapid increase in AI coding tools, I want more transparency in this area.

And what does that transparency give us? There's also nothing stopping a contributor from saying no even if they used AI.

[robertbastian]

I think the correct approach to do this is to update CONTRIBUTING.md, which should be a TC decision. Then you can update the template to align with that.

[Manishearth]

The PR author is responsible for all code they send for review, period.

I find it useful to know when team members have used AI. I've said this before but when I review code by project members the fact that the project member made a conscious choice to write that code factors in to my generally high-by-default confidence in it, and my general tendency to approve things.

But when an AI makes a choice and you review it it's not the same thing. There may have been better choices to make that I would expect Shane or Robert to notice when actively writing it, but less so when prompting an AI to fix a problem.

To me, "this PR was written by Shane" and "this PR was carefully reviewed by Shane" mean different things, and will have chances for different mistakes.

A project member saying "This PR was primarily generated by AI" to me is roughly equivalent as a project member's intern making a PR with the project member present during the creation process and mentoring.

A project member saying "this commit containing a pretty silly refactor was primarily generated by AI" is something where I probably won't care, though.

And what does that transparency give us? There's also nothing stopping a contributor from saying no even if they used AI.

If a contributor lies about it and it becomes obvious they are using an AI, well, then, we have an easy reason to not work with them. If a contributor is truthful about it we can have a conversation with them and ask them to not do so. It helps separate out the people who are trying to pull the wool over our eyes for GSOC points from people who are actually meaning to contribute but have not picked up on our stance on AI for newcomers.