docs: document expectations around AI use #11836

kirkwaiblinger · 2025-12-10T14:30:34Z

PR Checklist

Addresses an existing open issue: fixes Docs: Establish and document expectations around use of AI in contributions #11416
That issue was marked as accepting prs
Steps in Contributing were taken

Overview

I've just put up an initial message; iteration and criticism is very much invited!

@typescript-eslint/triage-team

typescript-eslint · 2025-12-10T14:30:37Z

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

netlify · 2025-12-10T14:30:39Z

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	`6deb5e3`
🔍 Latest deploy log	https://app.netlify.com/projects/typescript-eslint/deploys/69406dadfd9a88000866bdfb
😎 Deploy Preview	https://deploy-preview-11836--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 97 (🟢 up 18 from production) Accessibility: 97 (no change from production) Best Practices: 100 (no change from production) SEO: 92 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify project configuration.

nx-cloud · 2025-12-10T14:32:02Z

View your CI Pipeline Execution ↗ for commit 6deb5e3

Command	Status	Duration	Result
`nx run-many -t lint`	✅ Succeeded	3m 13s	View ↗
`nx run-many -t typecheck`	✅ Succeeded	1m 56s	View ↗
`nx test eslint-plugin-internal --coverage=false`	✅ Succeeded	4s	View ↗
`nx test typescript-estree --coverage=false`	✅ Succeeded	2s	View ↗
`nx run types:build`	✅ Succeeded	2s	View ↗
`nx test eslint-plugin --coverage=false`	✅ Succeeded	2s	View ↗
`nx run integration-tests:test`	✅ Succeeded	4s	View ↗
`nx run generate-configs`	✅ Succeeded	6s	View ↗
`Additional runs (29)`	✅ Succeeded	...	View ↗

☁️ Nx Cloud last updated this comment at 2025-12-15 20:27:01 UTC

rubiesonthesky · 2025-12-10T16:21:22Z

docs/contributing/Pull_Requests.mdx

+
+While we cannot and will not attempt to ban contributions which make use of AI, we ask that you use AI responsibly:
+
+- Always review AI-generated content closely


For me this is little vague does this mean the person who send the PR or reviewer. I guess kinda both.

Could this section be written even more cleaner, while stressing that before opening a PR make sure you have reviewed the code yourself, and that you can understand what it does and why. I fear that using language like “to champion” is not easiest to understand for people who are most likely to offend it.

Generally I think this is good addition and doesn’t sound too negative but keeps the welcoming spirit that this project has :)

I'd also suggest adding this:

Suggested change

- Always review AI-generated content closely

- Always review AI-generated content closely **_before submitting a PR._**

To emphasise that we don't want people to vibe a change, ping us with a PR creation and then review it later.

Added "before submitting a PR".

Re some of the language like "to champion".... I'm at a loss for a good idea to replace that. I want to convey that you should not only be able to do the feature, but also defend it, incorporate fixes/changes, and foresee potential impacts such as breaking changes or important interactions with other features. I lifted the "champion" wording from some of our canned responses on issues, see

typescript-eslint/.github/replies.yml

Lines 66 to 71 in 635133a

name: Progress - Blunt

- body: |

We are a community run project. The **volunteer** maintainers spend most of their time triaging issues and reviewing PRs. This means that most issues *will not progress* unless a member of the community steps up and **champions** it.

\

If this issue is important to you — consider being that champion.

If not — please use the subscribe function and wait patiently for someone else to implement this.

Open to suggestions

Perhaps it’s not necessary to get stuck on “to champion” wording here. I feel that the changes you did to other places, makes this wording less important to focus on. You can understand the overall idea of the whole segment and these guidelines, even if you didn’t understand what championing is in this context. :)

rubiesonthesky · 2025-12-10T16:25:09Z

docs/contributing/Pull_Requests.mdx

+- Only use AI for contributions that you would understand well enough to champion and respond to feedback on without making use of AI
+- Do not ignore our issue and PR templates
+
+Don't let this dissuade you from contributing to typescript-eslint! We are generally more than happy to assist new contributors and help them improve at our repo. We just are not interested in babysitting anyone's LLM instances.


Instead of saying babysitting, could it this address the problem I have seen, where the person opening PR is acting agent between reviewer and the LLM? “We are capable of running LLMs ourselves and we are not interested in prompting them via PR reviews”?

Good call out yeah.

If the persons entire role in the process is agentic middleman then we ask that they remove themselves from the process entirely and just not submit the PR.

We can talk to the agent without them as a go-between.

Reworded 👍

bradzacher · 2025-12-11T09:21:30Z

docs/contributing/Pull_Requests.mdx

+
+- Always review AI-generated content closely
+- Only use AI for contributions that you would understand well enough to champion and respond to feedback on without making use of AI
+- Do not ignore our issue and PR templates


Possible addition (or some variation of)

Avoid AI generated PR descriptions as they are usually just a verbatim summary of the code.

We require that you summarise your PR changes yourself in your own words. If you cannot summarise your change then you do not understand your change and should not be raising the PR.

Incorporated this

codecov · 2025-12-15T20:27:31Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.58%. Comparing base (dd96947) to head (6deb5e3).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #11836      +/-   ##
==========================================
+ Coverage   90.53%   90.58%   +0.04%     
==========================================
  Files         523      524       +1     
  Lines       53096    53324     +228     
  Branches     8838     8892      +54     
==========================================
+ Hits        48073    48301     +228     
  Misses       5010     5010              
  Partials       13       13

Flag	Coverage Δ
unittest	`90.58% <ø> (+0.04%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 9 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

JoshuaKGoldberg

I like the general direction but think we need to at least add a link. WDYT?

JoshuaKGoldberg · 2025-12-16T10:17:44Z

docs/contributing/Pull_Requests.mdx

 - Comment on a closed PR
  - Reasoning: It is much easier for maintainers to not lose track of things if they are posted as issues. If you think there's a bug in typescript-eslint, the right way to ask is to [file a new issue](https://github.com/typescript-eslint/typescript-eslint/issues/new/choose). The issue templates include helpful & necessary practices such as making sure you're on the latest version of all our packages. You can provide the link to the relevant PR to add more context.

+:::warning Contribution standards in the era of AI


We should have some way to # link to this - maybe either a heading or a hidden <div id="..." />? I'd bet we're going to want to link to it more and more. 🙃

JoshuaKGoldberg · 2025-12-16T10:19:26Z

docs/contributing/Pull_Requests.mdx


+:::warning Contribution standards in the era of AI
+
+We reserve the right to close PRs and issues that we deem to be poor quality and/or which we deem will take an undue amount of maintainer effort to make progress on.


This is kind of already implied by us being maintainers, no? I don't think we need to take up space for it. Or I don't think it needs to come first - at the most I think it's relevant as a conclusion from what follows.

Suggested change

We reserve the right to close PRs and issues that we deem to be poor quality and/or which we deem will take an undue amount of maintainer effort to make progress on.

JoshuaKGoldberg · 2025-12-16T10:38:19Z

docs/contributing/Pull_Requests.mdx

 - Comment on a closed PR
  - Reasoning: It is much easier for maintainers to not lose track of things if they are posted as issues. If you think there's a bug in typescript-eslint, the right way to ask is to [file a new issue](https://github.com/typescript-eslint/typescript-eslint/issues/new/choose). The issue templates include helpful & necessary practices such as making sure you're on the latest version of all our packages. You can provide the link to the relevant PR to add more context.

+:::warning Contribution standards in the era of AI


Going even further than the id point: this is pretty buried in the PRs page. It's not very discoverable. What do you think about making this a sub-page under Pull Requests altogether? Like, /contributing/pull-requests/ai-contributions?

I like the sub-page approach because:

It provides a single, central, quick resource we can link to

If we want to enourage people to read the full docs, we can always explicitly say "and also please read (insert docs link)"

By being a standalone page, we have more flexibility in putting more in it

docs: document expectations around AI use

8e1a518

kirkwaiblinger requested a review from a team December 10, 2025 14:30

kirkwaiblinger marked this pull request as ready for review December 10, 2025 14:31

rubiesonthesky reviewed Dec 10, 2025

View reviewed changes

This was referenced Dec 10, 2025

feat(typescript-estree): allow projectService to type-check virtual processor children #11827

Closed

feat(scope-manager): add ESLint 10 globals opt-in and guard #11832

Draft

bradzacher reviewed Dec 11, 2025

View reviewed changes

JoshuaKGoldberg mentioned this pull request Dec 11, 2025

Allow projectService to use the default project for virtual processor child files #11838

Closed

8 tasks

pr feedback

6deb5e3

kirkwaiblinger requested review from bradzacher and rubiesonthesky December 15, 2025 20:28

bradzacher approved these changes Dec 15, 2025

View reviewed changes

JoshuaKGoldberg requested changes Dec 16, 2025

View reviewed changes

JoshuaKGoldberg added the awaiting response Issues waiting for a reply from the OP or another party label Dec 16, 2025


		While we cannot and will not attempt to ban contributions which make use of AI, we ask that you use AI responsibly:

		- Always review AI-generated content closely

	name: Progress - Blunt
	- body: \|
	We are a community run project. The volunteer maintainers spend most of their time triaging issues and reviewing PRs. This means that most issues will not progress unless a member of the community steps up and champions it.
	\
	If this issue is important to you — consider being that champion.
	If not — please use the subscribe function and wait patiently for someone else to implement this.


		:::warning Contribution standards in the era of AI

		We reserve the right to close PRs and issues that we deem to be poor quality and/or which we deem will take an undue amount of maintainer effort to make progress on.

Uh oh!

docs: document expectations around AI use #11836

Are you sure you want to change the base?

docs: document expectations around AI use #11836

Conversation

kirkwaiblinger commented Dec 10, 2025

PR Checklist

Overview

Uh oh!

typescript-eslint bot commented Dec 10, 2025

Uh oh!

netlify bot commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for typescript-eslint ready!

Uh oh!

nx-cloud bot commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bradzacher Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bradzacher Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

netlify bot commented Dec 10, 2025 •

edited

Loading

nx-cloud bot commented Dec 10, 2025 •

edited

Loading

bradzacher Dec 11, 2025 •

edited

Loading

bradzacher Dec 11, 2025 •

edited

Loading

codecov bot commented Dec 15, 2025 •

edited

Loading