Looks good to me. I think calling out copilot like you are doing is good too since it's the built-in default for most GH things.

I think this AI Assistance Disclosure is a great idea.

I confirm this PR adheres to Django's contribution and security policies.

Obvioulsy all contributions should adhere to django's contribution and security policies, is the inclusion here as a checkbox because we expect a higher volume of lower quality submissions that don't follow the contribution guide with AI? Does the checkbox do enough for this.

Could we link to the relevant policies in the comment to help new contributors, I'm aware of the code contribution guides. https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
I'm not aware of docs that talk about security policies for contributing code. I'm aware of the security reporting guidelines and general django securty guide only.

Obvioulsy all contributions should adhere to django's contribution and security policies

Yeah actually I was just thinking: should that sit with the other checkboxes? 🤔

Why are we doing this? Can we get links to any other discussions leading to this...

I confirm this PR adheres to Django's contribution and security policies.

Obvioulsy all contributions should adhere to django's contribution and security policies, is the inclusion here as a checkbox because we expect a higher volume of lower quality submissions that don't follow the contribution guide with AI? Does the checkbox do enough for this.

I'm definitely open to tightening up the language and/or the format, though I'm also trying to keep the template lightweight for actual human contributors. The checkbox is aiming at being a low-friction nudge.

Would you have any suggestion? I'm very open to ideas!

Could we link to the relevant policies in the comment to help new contributors

Yes, absolutely, great point! (@RealOrangeOne is also suggesting this, so I'll push an update soon.)

I'm aware of the code contribution guides. https://docs.djangoproject.com/en/dev/internals/contributing/writing-code I'm not aware of docs that talk about security policies for contributing code. I'm aware of the security reporting guidelines and general django securty guide only.

You're correct: by "security policies" I primarily mean the security reporting guidelines and the expectations around responsible disclosure, not anything specific to code contributions per se. I can see how this could be a bit confusing and I'm happy to rephrase. I felt it was worth including it to emphasize that contributors (especially AI-assisted ones) should be aware of those boundaries and not propose PRs (which are inherently public) for (potential) security vulnerabilities.

Why are we doing this? Can we get links to any other discussions leading to this...

@adamchainz This change is meant to address the increase in lower-quality AI-generated submissions that the Fellows have been dealing with on a day-to-day basis.

Do you think this level of change warrants a forum post or broader discussion, given its impact on their workflow?

If you have specific concerns or suggestions, I’d love to hear them. Your earlier response came across as a bit dismissive, so I wanted to check if there's a particular reason you're hesitant about the change.

Your earlier response came across as a bit dismissive,

Just FYI I find Adam's generally a respectful person but is just thorough and likes to not see things creep too far...

I was also going to question the usefulness of it as it seems like rubber stamping but decided to wait and see where it was going. 👍

I watch all PRs as well and I've noticed the odd spam PR. I didn't realise it was that annoying but if it makes Natalia's and Sarah's life easier then sure 👍 ☺️

Sorry for being curt earlier! I meant nothing by it; I just wanted more context.

I am not confident that more steps will stop slop contributions being made, given how often folks delete or ignore the template. Looking back at recent unmerged PRs, none of the first ~10 spam ones used the template.

But if the fellows want to give it a try, sure, we can try. I will need to fill it in every time though, given I have copilot active...

I do think we need something given what I've heard from the Fellows about the growing number of un- or partially-reviewed AI generated PRs, especially with classics such as modules and functions that don't exist. I feel it's a relatively normal position to say "if you don't fully review your code, we are not going to either".

As such, I think we should add similar language to what we already have in the security policies about AI-generated reports to the general PR/contributions section, including the fact that obviously unreviewed/incorrect machine-generated PRs get closed without response and repeated acts will earn you a ban, and then also add some checklist items.

I think we can add less, though - I'd say just two checkboxes of either "I used no AI generation tools to create this pull request" or "I used AI generation tools to create the request, have disclosed them, and have fully reviewed their output" would be sufficient (two where you must pick exactly one is nice, as that way if someone just ticks every box you know they've not read it).

As such, I think we should add similar language to what we already have in the security policies about AI-generated reports to the general PR/contributions section, including the fact that obviously unreviewed/incorrect machine-generated PRs get closed without response and repeated acts will earn you a ban, and then also add some checklist items.

Good ideal, I will push this as a separated commit.

I think we can add less, though - I'd say just two checkboxes of either "I used no AI generation tools to create this pull request" or "I used AI generation tools to create the request, have disclosed them, and have fully reviewed their output" would be sufficient (two where you must pick exactly one is nice, as that way if someone just ticks every box you know they've not read it).

Makes sense, will tweak. Thank you!

Pushed updates as requested by @andrewgodwin. Could use an approval from a steering council member, or someone from the triage & review team or security team, so I'm allowed to merge.

Read this today, the whole piece is somewhat relevant, but this section in particular, links out to some other opensource projects and their AI contribution policies.
https://droettboom.com/blog/2025/07/13/how-to-think-about-llms-for-oss-development/#generative-ai-policies-for-open-source-software-packages