Skip to content

Conversation

@westonruter
Copy link
Member

Trac ticket: https://core.trac.wordpress.org/ticket/64587

This incorporates aspects of the PR template from the WordPress/performance repo, namely the new “Use of AI Tools” section.


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

@github-actions
Copy link

github-actions bot commented Feb 2, 2026

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props westonruter.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@westonruter westonruter requested a review from dmsnell February 2, 2026 19:05
@justlevine
Copy link

I'm not familiar with the conversation and Chesterton fences that went into WordPress/performance, but as I outline in WordPress/ai#77, I'd a recommend a checklist (or commented list if we care about GitHub UI semantics) versus a "free text" section.

IMO much better DX choice than expecting contributors - even if/after reading the guidelines- to intuitively know and remember what they need to proactively disclose / how granularly to go, etc. Also has the added benefit of guiding users to potential constructive uses of AI without being overbearing.

@westonruter
Copy link
Member Author

@justlevine I think that's a good suggestion, but I'm wary of adding too much to the template since it is currently pretty streamlined. Maybe start with simple freeform and links to the (in progress) guidelines and then iterate once the guidelines are more mature? Maybe the guidelines could have such a list of bullet points incorporated into it for copying into the PR template. It could even have an example PR template as part of the guidelines. My primary concern is to get something out the door sooner than later to help address the influx of PRs, many of which appear to be authored with in AI.

@justlevine
Copy link

justlevine commented Feb 2, 2026

@westonruter yup agree 100%, especially the part that anything at all is better than nothing.

Maybe the guidelines could have such a list of bullet points incorporated into it for copying into the PR template. It could even have an example PR template as part of the guidelines.

My hope is to create less cognitive load, so while I love the idea of providing some examples of what disclosure looks like, I think a copy->paste flow from an external ref document isn't worth the friction.

Still, even if it's just 1 extra sentence in the <!-- Section comment -->, I do think we should provide at least some same-place signposting. Personally, I feel it's more important to have this while waiting for the guidelines have time percolate, since the whole point is we're asking folks to do something now that's new to contributors, guideline authors, and really the entire ecosystem, before there's anywhere else to provide relatively clear direction.

(Related: Some fun reading at where folks are discussing the issues and potential tools GitHub could offer maintainers to triage slop https://github.com/orgs/community/discussions/185387)

@westonruter
Copy link
Member Author

Still, even if it's just 1 extra sentence in the <!-- Section comment -->, I do think we should provide at least some same-place signposting.

Would you add a suggestion for what you have in mind?

Comment on lines +23 to +27

<!--
You are free to use artificial intelligence (AI) tooling to contribute, but you must you disclose what tooling you are using and to what extent a pull request has been authored by AI. It is your responsibility to review and take responsibility for what AI generates. See the WordPress AI Guidelines: <https://make.wordpress.org/ai/handbook/ai-guidelines/>.
-->

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very much spit-balling and not married to any particular phrasing, just trying to list a plurality of acceptable usage as concisely as I can think to.

Suggested change
<!--
You are free to use artificial intelligence (AI) tooling to contribute, but you must you disclose what tooling you are using and to what extent a pull request has been authored by AI. It is your responsibility to review and take responsibility for what AI generates. See the WordPress AI Guidelines: <https://make.wordpress.org/ai/handbook/ai-guidelines/>.
-->
<!--
You may AI tooling to contribute, but it is your responsibly to review, understand, and take ownership of everything the LLM generates. You MUST disclose what tooling was used and where it was used.
For example, please specify if IDE Autocompletions used for code or docs; whether an agent or code harness provided the spec, created some methods or even the initial draft PR, backfilled tests, or generated any non-code assets; etc. See the WordPress AI Guidelines: <https://make.wordpress.org/ai/handbook/ai-guidelines/>.
-->

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is enumerating all of the acceptable usage needed? Wouldn't that be better to leave for the contributor to read from the AI Guidelines as they evolve?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So that's my argument is that it's precisely because AI Guidelines (both ours and general best practices) still have some evolution to do that we need some sort of tangible direction to make it clear we don't need -or want- a play-by-play, but rather something that indicates the signal-to-noise ratio for reviewers.

And to be clear, that's nowhere a full enumeration of acceptable usage, but I do think the rest of what matters can be mostly inferred from those while remaining relatively evergreen ;-) . It's a lot easier to broadly/blindly chunk with a checklist, so I'm doing my best with the constraint and I'm happy to dedupe any you feel are redundant.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be You may use AI tooling to contribute. Missing use

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants