CONTRIBUTING: make it clear that AI-generated PRs are not welcome

[jrfnl]

Includes a pull request template which also warns against this.

For the rationale behind this, please read the text in the CONTRIBUTING guide.

[dingo-d]

Left a few change suggestions.

[jrfnl]

Thanks for the review @dingo-d, applied nearly everything, left comments on what I didn't.

Note for whomever merges this: please SQUASH-merge the PR.

[GaryJones]

I can't support the framing of the changes here. It's too negative. It's too threatening, and while I understand the premise behind this change, I don't like it.

If a contributor has taken the time to look up the contributing documentation or read the comments in a PR template, then they are likely more conscientious than the individuals who send in PRs that appear to be generated by AI. In other words, the people these threats are aimed at are not the ones who will be reading these changes.

This change would only seemingly exist to grant us the permission to ban people from the repository. If someone is persistent in sending in low-quality PRs, then we already have the Code of Conduct process to follow.

Instead of "Words of Warning", let's frame it as "Tips for a successful PR", and then explain how the use of AI will nearly always lead to a poor changeset, and the impact on maintainers' time. We can still get the points across, and still have a section to point AI-generated PR authors to, without needing to litter our docs with threats of bans.

[jrfnl]

@GaryJones In that case, maybe you could submit an alternative PR for this ? I don't mind removing the "can get you banned" parts in favour of the code of conduct, but then we should adjust the CoC as it doesn't contain any grounds on which to ban someone for violating copyright or using AI.
And to be honest, I'm not keen to adjust the CoC as it is now standardized on the Contributor Convenant.

[GaryJones]

Tips for Successful PRs

We welcome contributions from everyone, and want your PR to have the best chance of being reviewed and merged. Here are a few tips that will help:

• Respect copyright.
  Only submit code that you wrote yourself or that comes from sources where the license allows inclusion. Contributions must not violate copyright or licensing terms, as this could create legal risks for the project and for you as a contributor.

• Avoid AI-generated code.
  While AI tools can sometimes help you think through ideas, PRs that include AI-generated code often need major rework. They may not follow coding standards, can lack context, and increase the time maintainers spend on reviews. Writing and explaining the code yourself makes your contribution clearer, higher-quality, and more likely to be merged.

• Focus on quality and clarity.
  Take time to explain why the change is needed, and include tests or examples where appropriate. Clear, self-written explanations are much easier to review.

• Think about long-term maintainability.
  Code should align with WordPress coding standards and be easy for others to read, understand, and maintain.

• Be collaborative.
  If you’re unsure about an approach, open an issue or draft PR first to start a conversation.

By following these tips, you’ll save time for both yourself and the maintainers — and increase the likelihood that your contribution can be merged smoothly.

[jrfnl]

@GaryJones Okay, I like the approach, but that still doesn't give us the means to ban people under the CoC for wasting our time with AI-generated PRs.

In my opinion, the paragraph about AI generated code is nowhere near strong enough about how problematic this is. It's also missing the part about copyright and licensing. This is pussy-footing, which, to me, is not good enough.

Writing and explaining the code yourself makes your contribution clearer, higher-quality, and more likely to be merged.

Higher quality ? Well... that very much depends on the contributor....

Clear, self-written explanations are much easier to review.

Clear, self-written explanations will make it more straight-forward for reviewers to understand what you are trying to do.

be easy for others to read,

Similar to the above, I'd suggest replacing "easy" with some other phrasing. This is ablist language.

[GaryJones]

that still doesn't give us the means to ban people under the CoC for wasting our time with AI-generated PRs

There are two overlapping issues here.

1. Discouraging low-quality AI PRs from the beginning.
2. Informing users that we could ban them from the repo.

The Tips section here handles 1. - even if it needs some strong guidance around copyright / licensing, etc.

I don't think we need to be explicit about 2, but we can refer to the CoC. If someone submits a low quality/AI PR, and doesn't take the advice / warning on board, and submits a new PR with the same low quality, then we can take steps at that point if needed. We're the maintainers. We don't need the explicit threat when we've already advised them of what they need to do (and can point them to the tips section) after the first PR. We can agree on wording for a GH saved reply if we want to streamline that feedback.

Here's some stronger wording:

---

Tips for Successful PRs

We welcome contributions from everyone, and want your PR to have the best chance of being reviewed and merged. To help with this, please keep the following in mind:

• Respect copyright and licensing.
  Only submit code that you have written yourself or that comes from sources where the license clearly allows inclusion. Submitting code that infringes on copyright or licensing terms puts both you and the project at legal risk, and such contributions cannot be accepted.

• Do not submit AI-generated code.
  Pull requests containing AI-generated code are not acceptable. Beyond copyright and licensing uncertainties, AI-generated contributions consistently require disproportionate amounts of maintainer time to review, correct, or rewrite. This wastes limited project resources and slows progress for everyone. Submitting AI-generated code may be treated as a violation of our Code of Conduct.

• Focus on quality and clarity.
  Take time to explain why the change is needed, and include tests or examples where appropriate. Clear, self-written explanations make it more straightforward for reviewers to understand what you are trying to achieve.

• Think about long-term maintainability.
  Code should align with WordPress coding standards and be written in a way that others can readily read, understand, and maintain.

• Be collaborative.
  If you’re unsure about an approach, open an issue or draft PR first to start a conversation.

By following these tips, you’ll save time for both yourself and the maintainers — and increase the likelihood that your contribution can be merged smoothly.

[jrfnl]

PR #2598 has now been opened with the alternative approach for the CONTIBUTING guide. Once that PR has been merged, I will remove the suggested change to the CONTRIBUTING guide from this PR, leaving just the PR template.

Consider this PR blocked until PR #2598 has been merged.