Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.9k
docs: document expectations around AI use#11836
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Conversation
Thanks for the PR,@kirkwaiblinger! 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 onhttps://opencollective.com/typescript-eslint. |
netlifybot commentedDec 10, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
✅ Deploy Preview fortypescript-eslint ready!
To edit notification comments on pull requests, go to yourNetlify project configuration. |
nx-cloudbot commentedDec 10, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
View yourCI Pipeline Execution ↗ for commit6deb5e3
☁️Nx Cloud last updated this comment at |
docs/contributing/Pull_Requests.mdx Outdated
| 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 :)
bradzacherDec 11, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I'd also suggest adding this:
| - 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 in635133a
| 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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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. :)
docs/contributing/Pull_Requests.mdx Outdated
| - 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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”?
bradzacherDec 11, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Reworded 👍
| - 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Incorporated this
codecovbot commentedDec 15, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Codecov Report✅ All modified and coverable lines are covered by tests. 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
Flags with carried forward coverage won't be shown.Click here to find out more. 🚀 New features to boost your workflow:
|
JoshuaKGoldberg left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I like the general direction but think we need to at least add a link. WDYT?
| - 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
We should have some way to# link to this - maybe either a heading or a hidden<div />? I'd bet we're going to want to link to it more and more. 🙃
| :::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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
| 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. |
| - 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Going even further than theid point: this is pretty buried in the PRs page. It's not very discoverable. What do you think about making this a sub-page underPull 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
PR Checklist
Overview
I've just put up an initial message; iteration and criticism is very much invited!
@typescript-eslint/triage-team